ティックの透明度

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

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

100%pure .net OS

100%pure .net OSの夢

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

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

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

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

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

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

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

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

ジー

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