ここ数カ月で残念ながら疎遠になった相手から「(Kandoが)あちこちで私の悪口を言いふらしている」というご批判のメールを頂いたが、心当たりがない。
まずアチコチというほど私がプライベートの人間関係について何かを書いている場所は多くない。

まずBlogとかはここ1年以上は休眠放置だし、PixivやCosplyers ArchiveとかCircle.msとかの目的特化のSNSではそれ系のことしか書いてないから関係ないだろう。
Facebook、LinkedIn、MENDELEY、Reserchmap、は仕事上の都合で始めただけに大体仕事関係の人や物事に関わることしか書いていないからやっぱり関係ないだろう。
Wikipediaや借力もプライベートの人間関係について書く機会はまぁ、ない。（…というか近頃、借力は放置気味だ。）

匿名掲示板の類はもう何年も利用していない。たまに検索でそれらやそれらのコピペBlogの類がかかると読むだけだ。
…が、件の人物はそのあたりをよく読んでいて、批判されてないか、晒されてないか気にしているようなので、
もしかしたら匿名の誰かが書いたレス（もしかすると/.JPやTwitterからのコピペかもしれない）を私が書いていると思っているのかもしれない。
仮にそうだとするとそれが私でないと言う「証明」は難しい。そんなことをするほどに暇ではないのではあるが…。

…とすると残るのはこの/.J（コメントと日記）とTwitter(サブアカウント)ということになる。
（TogetterはTwitterに含めて考えている。収集されたTweetはもちろん、殆どのTogetterコメントはTwitterに流しているから。）

で、そのTwitterと/.JP範囲についても特定の個人について「悪口」を書いた記憶はやはりない。
ある意見、行動を指して批判したり、個人的に受け入れがたいというようなことを表明したことはあるので、強いて言えばそれが近いか。
合理的な根拠があるような場合は批判するし、主観的な評価の場合は個人的に受け入れがたいと書いてきた。
ただいずれにしても対象は意見や行為であって、それを行った個人ではないつもりではある。
それにそもそも名指ししない限り、多くは一般論であって特定の個人を念頭に置いてない。
さらに言えば、/.JPやTwitterでこの数カ月以内にその件の個人を名指ししたことはない。
（かつて相互フォローしてた頃にはリプライを飛ばしたことはある。）

が、まぁこちらは一般論のつもりであったり、あるいは行為や意見を批判しているつもりでも
相手がそう受け取らないで、自分個人に対する誹謗・中傷だと取ることはあるだろう。
特に議論に慣れてない人は、∀と∃の区別がついてなかったり、行動や意見の類型に対する批判を個人への悪口に取ることが多いような印象は以前からある。
そしてそういう受け取り側の解釈を止める手段はこちらにはない。そういう受け取り方をすると当人が不幸になるだけだと思うのだが…。

…という以上の文章は珍しく件の特定の個人が読んでいる可能性を念頭に置いて書いているが、
結局、内容の殆どは私の情報発信ポリシーを説明しているにすぎないなぁ。

追伸的に私信を書くと、件の本人はもはや信じないだろうけど、
別に私はその人のことが積極的に憎いとか嫌いとかではないしなぁ。
ただそれまでのような付き合い方や、期待に応えることが私には能力的に無理だと思い、
かといってこちらに合わせてもらうのもその相手には無理だろうと予想できたので、
諦めて距離をおくに至ったというだけであってね。
この文章も全然悪口のつもりはないが、見たら言い訳や悪口に取るのかなぁ。
そうなっても不幸なのはそう解釈した本人だけで、私個人は困らないといえば困らないが…。

※メールの返事をしないでここに書いたのは件の本人がもはや私の/.JP日記やTwitterを見てない＝解放されているなら知る必要のないことだから。

職場の研究室のWebページを、研究室のメンバーが他で登録したSNSのプロフィールや文献管理サイトから情報をAPIで取得し
（ハヤリの）「マッシュアップ」して自動作成したいので調査すべしという仕事が降ってきた。
で、様子見のために幾つかのSNSに入ってみる流れになった…。

で、入ってみたので晒してみる：

Facebook
http://www.facebook.com/profile.php?id=100002451996214
LinkedIn
http://www.linkedin.com/profile/view?locale=ja_JP&id=118014109
Mendeley
http://www.mendeley.com/profiles/takayuki-kando/

以下はまだチェックしただけで入ってない研究者向けSNS：
Methodspace
http://www.methodspace.com/
academia.edu
http://www.academia.edu/

ところで:
我が国、国情研が誇る
「Researchmap リサーチマップ - 研究者向けサイエンス2.0基盤サービス」 http://researchmap.jp/
は「科研費番号科研費研究者番号」が入会時にいるというので一旦パス。（今の身分だとない。昔もらった研究者番号で入会できました。）
ちなみに 科研費番号科研費研究者番号がない場合は研究者かどうか審査するので主要な論文を提示して申請しろと言う別のフォームも一応あるが…入りにくいサービスには違いない。
まぁ、科研費申請と連動させたいのはわかるがオプションじゃなくて必須にされてしまうとなぁ…。

2011/05/16
科研費番号ではなく科研費研究者番号ではないかという指摘を頂いて確認したところ入会できたので訂正。

つい衝動的にモデ権全弾をエイプリルフールなストーリーにつぎ込んでエイプリルフール的センスでモデをつけてしまった。
明日になったら何か投稿して消しておいた方がいいかなぁ？

http://slashdot.jp/slash/comments.pl?sid=527709&cid=1928856で職場は東北電力提供のEグループであったｗ
エイプリルフールって電力会社がサービスするのかｗ

IaaS系のクラウドを意識しつつ仮想マシンを管理するAPIについて調べてみるなど。

とりあえず手元に資料があったXen、VMWare、Amazon EC2あたりから取りかかってみた。

AmazonのEC2がXenベースらしいことはわかった（ソースはWikipedia）。
もっとも、Xen API（http://wiki.xensource.com/xenwiki/XenApi）のXen-RPCが利用できるかどうかはまだ分からない。
Xen-RPCだとJavaから使うにはXML-RPC経由らしいことを知って若干面倒くさそうな気がしてきた。
（Apache XML-RPCを使うことになるのかな？
PythonバインディングとCバインディングはあるというのだが…。JavaバインディングはToDoと書いてあった。）

VMWareだとvSphere API(http://www.vmware.com/support/developer/vc-sdk/)と言うものがあるらしい。
JavaからだとSOAPでまた面倒くさそうな気がしないでもない。
（Apache Axis2を使うことになるのかな？
PerlバインディングとPowerShellバインディングはあるというのだが…。）

…自分でやるんじゃなくて人に頼むことになる予定なのであんまりご無体なことも言いにくいしなぁ。
既にXMPPとかEclipseプラグインだとかあんまりこれまで要素技術として使ったことのない種類の技術を取りこんで設計案書いてるからなぁ。

仮想マシンの管理APIがこんな面倒くさそうな状況になっていようとは…。
プロセス起動くらいの気楽さで仮想マシンイメージやテンプレートから仮想マシン起動できるくらいのお気楽さを期待していたのだが…。

作業工程的にもローカルの仮想マシン環境である程度汎用に作っておいてクラウド移行とか考えていたんだが…。
富士通Trusted-Service Platformとさくらのクラウドの情報も軽くさらってみた様子では
クラウド・ベンダの皆さまは取りあえず自前APIとか作ってらっしゃるようなので持っていくのが大変そうだ…。
Xen→Amazon EC2はいけるのかもしれないがハッキリしないしなぁ。

…標準化に関しては標準化団体DMTF(http://www.dmtf.org/)とOGF(http://www.gridforum.org/)まで辿りついて斜め読みしたところで力尽きた。
ユーザー的にみると標準化はまだ先っぽいことは取りあえずなんとなく分かった…。
仮想マシンの管理APIが高機能で標準化されているなら、
XMPPのボットをエージェント代わりにするようなXMPP濫用的設計は止めてそっちを使う選択もあるのだが標準化が遠いのが致命的な予感。

Togetterまとめ
腐のマナーとかモラルについて考えてみた
http://togetter.com/li/95580

…に「面倒な慣習」と評する
批判的なコメント（@ChihiroShiiji名義）を残したことについて
個人的なチャネルで「気分を害した」と謝罪要求がきたためそれに対する応答を公開。
（以下の文中の「あなた方」は「気分を害した」と表明した当人とそのお友達を指す。）

----

結論：

自分の発言内容に恥じるところはなく反省すべきとは思えません。
気分を害された方々はお気の毒とは思いますが、
ある慣習を選択するという各人の選択と感性は
私の発言に伴う責任の範囲外であり、
私が反省すべきとは思いません。
そして反省すべきと思っていないことを謝罪するつもりはありません。

詳細：

不合理な慣習による面倒を面倒と述べることに問題があるとは思いません。
自ら選んで不合理な考えに基づいて行動しておいて
それを批判されて傷ついた謝罪せよといわれても困ります。
それは何ていう地雷ですか。

批判とは命令や指図ではありません。
不合理だからやめろとあなた方に言っているわけではありません。
あなた方の不合理に付き合っていく他者にとっては
面倒な慣習だと評しただけです。
他者にとって不合理で面倒な慣習でも、それに他者を従わせる価値があると
あなた方が信じるならば今後もつづければよろしいでしょう。
仮に私個人が沈黙したとしても折に触れて批判は止まないと思いますが、
不合理なことでも続ける自由はあります。

私に関しては現に不合理で面倒と考えていても
他に価値（人間関係を維持することによる喜び）がある
と考えたから実際の行動としてはこれまで従ってきたわけです。
従ってきたけれど、その不合理な面倒事をについて
不合理で面倒だと発言する表現の自由まで放棄したつもりはありません。

私は不合理で面倒なことを不合理で面倒だと表明する自由がないのでしょうか？
あなた方との関係に限定すれば不合理で面倒なことに承知の上で
従ってきたわけですが、その実績は評価されないのでしょうか？

行為・慣習に対する批判と、それを行う人間に対する悪口とは異なるものです。
分けて考えていただく方がお互いのためだと思います。

職場の男性（特任研究員・有期雇用）が育児休暇を取ろうとしたら：
勤務先「無給でよければいつでも＜休業＞していいお？ (^ω^ )」
ハロワ「給付期間中の雇用が保障されてるならあげるお？(｀・ω・´ )ｷﾘｯ」
のコンボで事実上、有期雇用者は無収入の休業以外選択肢がない模様…なんて役に立たない制度…。
せっかくイクメン志願者がいるというのに…。

後日談（2011年2月19日追記）：
件のイクメン志願者は別プロジェクトに呼ばれて所属組織を移るようです。
＃育休の件が関係あるかどうかは知りません。

Twitterで@nagise氏が書いていた：

・http://twitter.com/#!/nagise/status/29524997517090816

から@nagise氏によって書かれたBlogエントリ:

・HttpSessionを型安全にする

を読んで、2レベル計算という考え方ではどう理解できるかについて思ったことをまとめ。

コンパイルにおける様々な最適化や型検査、総称型を考えるときに便利な考え方の一つとして多レベル計算がある。
コンパイラが行う各種の変換を、プログラムが本来実行すべき計算を多段に分けて計算していると捉える見方である。
特にコンパイル時の処理と実行時の処理というように2段階に分けて計算が実行されると考えた場合は2レベル計算と呼ばれる。

2レベル計算のもっとも簡単な例は最適化における定数の畳みこみで、以下のような定義があった時：

public class Constants{
    //...
    public static final int A = 1;
    public static final int B = 2;
    public static final int C = 3;
    public static final int TOTAL = A+B+C;
}

（package文は省略、以下同様にpackage文とimport文は省略する。）

このコードを字面通り実行するなら実行時にA、B、Cが参照され、1+2+3が計算されTOTALの初期値に用いられることになるが、
通常のコンパイラは1+2+3を実行時に計算せず、コンパイル時に計算して実行時にはTOTAL = 6として参照できるようにする。

これを通常は、コンパイラ視点に立ってコンパイラが対象となるプログラムを変換していると捉えるわけだが、
2レベル計算の視点ではプログラムの立場に立って（？）なすべき計算を2段階に分け、
計算の一部がコンパイル時（コンパイル・タイム）に実行され、
残りがプログラムの実行時（ラン・タイム）に実行されると考える。
(実行タイミングと依存関係がない演算の実行順序は変わるが型情報も含め「データフロー」は変わらない。)

コンパイルにおける総称型の処理も（実際の実装はともかく）一種の2レベル計算と考えることができる。
例えば総称型：

public interface Map<K,V>{
    void put(K key, V val);
    V get(K key);
    //...misc
}

はコンパイル時に計算されされる「関数」と考えることができる。
この「関数」の「引数」はK,Vであり、例えばこれらにそれぞれString, Integerを引数として指定した「返り値」が

public interface Map<String,Integer>{
    void put(String key, Integer val);
    Integer get(String key);
    //...misc
}

というクラス型（ここでは実際にはインターフェース型、以下この日記ではクラス型、インターフェース型ひっくるめて具象型と書く）の定義となる。

同様にして

public class KeyValueStore {
    private final Map<Key<?>, Object> map = new HashMap<Key<?>, Object>();
 
    public <T> void put(Key<T> key, T value){
        map.put(key, value);
    }
 
    @SuppressWarnings("unchecked")
    public <T> T get(Key<T> key){
        return (T)map.get(key);
    }
}

に見られるような
総称メソッド

    public <T> void put(Key<T> key, T value){
        map.put(key, value);
    }

や

    public <T> T get(Key<T> key){
        return (T)map.get(key);
    }

は引数Tに具象型を取って型変数を含まないメソッド:

    public String void put(Key<String> key, T value){
        map.put(key, value);
    }

(TとしてStringが渡された場合)
や

    public Integer T get(Key<Integer> key){
        return (Integer)map.get(key);
    }

(TとしてIntegerが渡された場合)
を返す「関数」と考えることができる。

ところで先にのKeyValueStoreクラスはKeyとしては例えば以下の様なものを利用することを考えている。

public final class Key<T> {
    private Key() {}
 
    public static final Key<String> NAME = new Key<String>();
    public static final Key<Integer> AGE = new Key<Integer>();
    public static final Key<String> JOB = new Key<String>();
    public static final Key<Integer> ID_NUM = new Key<Integer>();
}

これは要するに「列挙」であるが、オブジェクトに型情報も持たせる目的で型パラメタを利用するため言語に組み込みのEnumではなくTypesafeEnumパターンを利用している。

これらを使うと以下の様なコードが実行できる。

public class TestKeyValue {
    public final static String EXPECTED_NAME = "Chihiro";
    private static final int EXPECTED_AGE = 17;
    public final static String EXPECTED_JOB = "Student";
    private static final int EXPECTED_ID_NUM = 4;
 
    @Test
    public void testKeyvalue(){
        KeyValueStore kvStore = new KeyValueStore();
 
        kvStore.put(Key.NAME, EXPECTED_NAME);
        kvStore.put(Key.AGE, EXPECTED_AGE);
        kvStore.put(Key.JOB, EXPECTED_JOB);
        kvStore.put(Key.ID_NUM, EXPECTED_ID_NUM);
 
        String v1 = kvStore.get(Key.NAME);
        assertEquals(EXPECTED_NAME, v1);
 
        int v2 = kvStore.get(Key.AGE);
        assertEquals(EXPECTED_AGE, v2);
 
        String job = kvStore.get(Key.JOB);
        assertEquals(EXPECTED_JOB, job);
 
        int id_num = kvStore.get(Key.ID_NUM);
        assertEquals(EXPECTED_ID_NUM, id_num);
    }
}

つまり型安全（≒実行時にエラーになるような間違いの可能性があるキャストが利用側で必要でない）なget/putを備えた
型つき属性リストのようなものが実現できる。
（ネタ元の「HttpSessionを型安全にする」では
javax.servlet.http.HttpSessionのsetAttribute()/getAttribute()を型安全にしたいという動機で始まっている。）

しかしこの場合KeyValueStoreに対しKeyが固定で差し替えが効かないので
新しい一群のキーについて毎度KeyとKeyValueStore相当のクラスを対にして定義することになる。
Keyの方はEnumなので我慢するとしても、KeyValueStoreは毎回ほとんど同じなのでこれは煩雑である。
また上の例のKeyValueStoreくらいなら簡単だから間違いも少ないだろうが、
もっと複雑な機能を提供する場合は間違いやすい面倒な作業になるだろう。
（例えばKeyの値毎に範囲チェックを提供するとか効率のよいリーダ/ライタ型の並列アクセスを可能にするとか、
ヒストリやデフォルト値を提供するとか…。）

そこで以下の様に：

public class GenericKeyValueStore<K> {
    private final Map<K<?>, Object> map = new HashMap<Key<?>, Object>();
 
    public <T> void put(K<T> key, T value){
        map.put(key, value);
    }
 
    @SuppressWarnings("unchecked")
    public <T> T get(K<T> key){
        return (T)map.get(key);
    }
}

KeyValueStoreを総称型（GenericKeyValueStore<K>）に変えてにパラメタとしてKey相当の型を定義して引数に与えれば
KeyValueStoreは使いまわせるのに…できない。これは残念というのがネタ元の「HttpSessionを型安全にする」の嘆き。
そして@nagise氏はこの状況を「型変数Kが型変数Tを取れない」と表現するのだが、どうもこれが判りにくいように思えたのが今回の日記を書いた動機。

このGenericKeyValueStore<K>を2レベル計算的に見ると、
問題点は「Javaにおいては総称を表現する『関数』の定義域は具象型である。」に違反することにある。
なぜならばKey<T>のような存在は「具象型を取るTを引数とし、具象型を返り値とする『関数』」であってそれ自身は具象型ではない。
（『関数』Keyの引数Tに具象型としてStringやIntegerといったものを適用した結果は具象型になるが、
未評価の引数が残っているK<T>は『関数』である。）

では何故Javaの総称型を表現する『関数』の定義域は具象型に制限されているのだろうか？

これは関数の引数の評価に際し許される演算が置換（型引数を具象型に置換する）だけなので、
当然の結果として、定義域に『関数』を含めると値域も『関数』になってしまわざるをえないことにある。

（特殊な例外として『定数関数』のような例はある。
引数Tが定義本体に現れず、Tに渡された具象型がなんであったとしても同じ結果、
つまり一定の具象型や一定のメソッドを返すような関数である。
これをチェックして認めることは可能だろうが複雑さの増加に対して得られるものは殆どない。）

これは型に関する『関数』の『高階関数』にあたるものになる。
そのようなものの実現は不可能ではないし、可能になれば表現力は増すだろうが、処理系の複雑さは相当増す。

例えば実行時に『関数』が利用できることにするとクラスファイルに総称型の表現を追加し、
JavaVMに総称型の適用機能を追加する必要がある。この場合イレイジャによるお手軽かつ互換性を維持した実装は不可能になる。

また実行時に『関数』を利用できない制限をした場合でも、コンパイラが『高階関数』を実現する必要がある。
通常ならば定義された総称の数だけ『関数』の定義が存在するだけであり、
特にイレイジャによる実装であれば置換して型チェックしてキャスト追加して終わりになるところが、
置換した結果『関数』定義が増加することになる。

…とまぁ2レベル計算的にはこういう具合に理解できると思う。
とはいえJavaの総称型程度だと道具立てが大仰過ぎるかもしれないが…。

C++の総称型であるtemplate機能の場合は条件分岐と整数演算、再帰定義が可能であり、
実際にかなり高度な計算の記述が可能になることから2レベル計算的なイメージはコードの理解の役に立つのであるが…。
（手前味噌的実例ではtemplateにより浮動小数点演算、三角関数、FFTのループの展開、整数計画法を実際に記述してコンパイル時に計算させている。）

…ところで、この話題には後日続きがあった。
続きについてのコメントは次回の日記で。

お仕事で作っているちょと変わったコンパイラの中の主要だけれどソフトウェア工学的に少々問題のある（婉曲表現）モジュールを書き直すついでに、
使っているコンパイラ・フレームワークをCOINS（Java）からLLVM（C++）に移すかもしれない。

私自身はC++歴の方が長いので、私自身がC++コードを書くことにそれほど不安はないが、チームの面子のスキルと支援ツールには若干不安がある。
チームの面子のスキルは未知数なところがあるので脇へ置くとして、支援ツールくらいはなんとかしたいもの。

現状はEclipseでJavaなのだが、C++に移るとしてEclipseのC/C++開発環境CDTのリファクタリング機能はJDTのリファクタリング機能に比べ心もとない。
ユニットテストに関しては以前TUTを少しだけ使ってみたことはあるのだが、他にもっといいものがあれば移りたいところ…。

ということでこの日記に見つけた物をまとめていく試み。

リファクタリング・ツール
一覧

CDT

Eclipseの標準C/C++開発環境プラグイン

Refactor! - Free Refactoring Tool for C++ Developers

VisualStudio向け。無償（VisualStudioExpressでは利用不可）。

Visual Assist X

VisualStudio向け。wholetomato社。$249。

The DMS® Software Reengineering Toolkit

総合的なソフトウェア・リエンジニアリングツール。
リファクタリングもできるがそれだけではなく、各種解析や整形、言語間の変換なども含む。IDEとは協調しない独立ツール。
Semantic Designs社、価格書いてないけど如何にも高価そうな…。

…

…。

（以下収集中。）

情報源・解説記事

• …

（以下収集中。）

ユニットテスト・フレームワーク
一覧

CppUnit - C++ port of JUnit

JUnitの移植。とりあえずメジャー処？

NUnit

.Net環境用。.Net環境でC++を書くなら使えなくはない？

TUT - C++ Template Unit Test Framework

テンプレート利用。

…

…。

（以下収集中。）

情報源・解説記事

• C++開発者のための単体テスト入門
• List of unit testing frameworks - C++(←Wikipedia英語版…見たついでに日本語版向けに翻訳中 翻訳した。)
  …しかし、ちょっと数年C++から離れてJavaで仕事してる間にC++用のユニットテスト・フレームワークが「多すぎて問題」になるほど増殖していたとは…。

（以下収集中。）

あけましておめでとうございます。
旧年中はお世話になりました。本年もよろしくお願いします。
＜年賀状＞

okky氏日記経由でモナー神社へ初詣ｗ

【大吉】 (No.14356) モナー神社
願事 : 思いがけぬ人の助けありて叶う
待人 : 来るべし 驚く事あり
失物 : 出づべし
旅立 : 遠方に行き利益有り
商売 : 進みて吉 利益あり
学問 : 安心して勉学せよ
争事 : 勝ち制す事十分なり
転居 : 差し支えなし 上吉
病気 : 快癒すべし
縁談 : 近き方よし

開催日：2010年12月31日(金)10時～16時
配置場所：東P36a
コメント：コスプレ女装からＧＩＤまで女装に関する体験談、
ノウハウ、想い、理論等を漫画、イラスト、エッセイ、写真等で綴ります。
基本的に全年齢向け。新刊は実践系女装本「さんふらわーNo.30」
女装写真撮影話などを予定。今回、短いですが当事者による女性ホルモン話の寄稿も頂きました。

詳細はコチラ：http://c10007001.circle.ms/cr/pp/Paper.aspx?CPID=164284

…まだ原稿描いてるんですけどね…。