ビネツ

37.2度。不気味な微妙な微熱はいつものことだけど、実際に顔がほてる感じは珍しい。数日続いている。

確率的な発注枚数

最大建て可能枚数の半分＋コイントスの連続成功回数を売買枚数とするようにするには以下のようにカスタマイズします。

C:\Documents and Settings\ユーザ名\Local Settings\Application Data
　\CLICK-SECHatchukunPlus.exe_なんちゃら\なんちゃらのuser.config
の中の<configuration>要素内の<usersettings>要素内の<tomorrowplusplus.mimohuta.properties.settings>要素内に

<setting name="TransactionQuantityDecider" serializeas="String">
<value>
using System;
using System.Linq;
namespace Tomorrowplusplus.Mimohuta{
public class TransactionQuantityDecider{
Random random=new Random();
public int decide(int max){
int min=(int)Math.Ceiling(max/2.0);
return min+Enumerable.Repeat(1,max-min)
.TakeWhile((i)=&gt;random.NextDouble()&lt;0.5).Sum();
}
}
}
</value>
</setting>
<setting name="TransactionQuantityDecider_RequiredAssemblies" serializeas="String">
<value>System.Core.dll, mscorlib.dll</value>
</setting>

と記述します。

Linqが便利すぎて泣けてくる。それにC#コードで直接動作をカスタムするなんて高級な機能がいとも簡単に実現するCODEDOMとか本当C#って素敵。C#コードとは言えxml中に記述するので不等号や＆を文字実体参照に置き換えなければいけないのが面倒だけど。

出た当初には見向きもせずにV3.0になってから使い出したから手放しに絶賛できるんだろうなあ。

37.7度

熱が朝37.4、さっき37.6、今37.7度と順調に上がっている。微熱にすぎないのでこれ自体は問題なくって顔が熱っぽい程度。

ただ、リンパ節の腫れがないのと微熱が軽度(～37.2)という事で橋本先生の分類でいう身体表現性障害類似型に分類されて(のと実際に鑑別不能型でなくいずれかの類型にあてはまる身体表現性障害の可能性も検討しての事だろうけれど)坪井先生を紹介されたんだけど、やはり激しい咳・痰の慢性化が全ての始まりだったのがいつも気になっていたので、橋本先生の分類で言う感染症類似型の類型の可能性が自分では今でも気になっている。このままリンパの腫れとかまで出て来たりして。まあ、通常の身体表製障害だったとしたら特に、そうでないとしてもやっぱり、気にしすぎで逆に症状が出る・悪化する事もあるわけだから、辛くないかぎりは気にしない事にしよう。

ジーテン

また起きたら重力10倍。あと気をつけていても喉が悪い。咳と痰がひどくなってきた。全ての始まりもそこからだったからなあ。ひどくなってほしくないなあ。

ティックの透明度

ティックの透明度を変えられるようにした。これで直近についてもティックよりも四本値＆秒間出来高を見たいというニーズに対応できる。さらに、四本値の四辺形があまり太らないようにした。一つしかデータ点がないような状況(ローソクがただの横線になるような状況)でエッジしか見えなくなるのが嫌で四辺形の頂点を少しオフセットしていたのだが、それを調整して小さめにした。

あと、readme.txtに書いておいた発注枚数決定方法のカスタマイズ例が間違っているのを直しておいた。これ、スクリプトなんかを組み込む労力をかける気になれなかったのでC#コードの動的コンパイルをしている。なので自分が書いたコード的には超シンプルだが、内部的にやっていることは超大げさ。

100%pure .net OS

100%pure .net OSの夢

アセンブリは名前とバージョン番号を持つ。それらはバージョン番号でソートされた適当なデータ構造のリストに格納され、このリストはさらに名前をキーとするハッシュテーブル(辞書)に格納される。

＃ハッシュテーブルでは全項目のリストアップにハッシュテーブルサイズだけの時間がかかる。でもはっしゅテーブルのサイズは普通アダプティブに増加させていくものだし、この場合アセンブリの個数というのは高速化を考慮しなければいけない程の量にはならないだろうから、現状の.netのDictionary.Keysにforeachするみたいな方法で全ての保持しているアセンブリをリストするなんて事は気軽にできるはずだ。
＃ここでハッシュテーブルというデータ構造を選択しているのはハッシュテーブル特有の種々の高速なO(1)操作が使いたいわけではなく、要するに、フォルダを指定してインストールという意味のないインストール操作を排除できる事が超超超重要なのだ。あれ、本当に意味が分からないよね。

アセンブリからアセンブリへの参照は名前及びバージョンに対して対応状況を判定するデリゲードによって指定される。Enumerable.Lastメソッドみたいな感じで見つかった最新の対応バージョンを参照する。

ユーザも仮想的なオブジェクトとしてアプリケーションのエントリポイントを持つアセンブリへの参照をやはり名前とバージョンの対応状況判定デリゲードで持つ(常に最新バージョンを使うor必要なバージョンのリストを指定する、みたいなGUIによる設定が必要だろう)。

後はガベージコレクションでアンインストールは自動だぜ！！。インストール時にフォルダを指定するなんて一般のユーザにやらせるには低級でレガシーすぎる操作はもう要らないぜ！。ディレクトリツリーベース(あるいはタグベース)のファイルシステムはユーザが作成するドキュメントファイルのためだけに使うぜ！！

技術的問題点は皆無なのが空恐ろしい。しかしこんなのがオーバーヘッドの問題なく実現するのは一体いつの時代なのだろうか。

しかも、これで、ハッシュテーブルをインターネットに置くようにすれば・・・。バージョン管理システムや入依存関係解決付きのパッケージ管理システムがおもちゃのように見えてくる。開発初期段階のアルファバージョンだろうと、技術的な問題のテストとして作ったトイライブラリだろうと、世界中のどこかで誰かがまだそれを必要としている限りはガベージコレクトされずに生き残り、誰も必要としなくなった後にいつのまにかガベージコレクトされてひっそりと消えていくわけだ。

はじめnetびいきで書き始めたけど、こうやって書いてみると、むしろグーグル向きのアイデアだなあ。

ジー

起きたら重力が10倍になっていた。俺は修行中の孫悟空か。
しかも風邪気味の症状が強まるし。今はそれでも辛いほどではないけれど、全ての始まりがここからだったのと、高校～大学の頃は声がかれる程の咳と痰が慢性化して本当に苦しかったので、その状況が再び訪れたらちょっと耐えられそうにないぞ。でも、今年の7月くらいからこの風邪気味の症状が再発してからは、以前ほどの強さじゃなくて、ゲホゲホ言いながら医者に行ってこれは関係ないので気にしないでくださいと言うわけにもいかないから一応申告するだけという感じの不気味な感じで、やっぱり以前とは違うんだよなあ。この部分については少しだけ体が適応したのかも去年までの二年間はパタリと止んでいたわけだし。