定期的に指標の見直しを行っていることは、以前から書いている。
ここのところMySQLで蓄積している、シミュレーションの結果を、
Accessでリンクして検証している。
当初は修正が楽で、見やすいと思っていたが、数字の羅列だらけで、
読み切るのに時間がかかる。
その結果、指標の見直しが、2,3ヶ月に1回になってしまい、
折角のシミュレーション結果が、リアルに生かせていないと感じていた。
Accessでなんとかできないかと思ったが、グラフを作ったり、
分析を縦横無尽に行うには、どうもAccessの動きが鈍くて、
見るに堪えない状況になった。
結局数年前に検討した、Webアプリ化するのが、一番楽だということで、
今日から作り始める。
折角なので現在のシステムの稼働状況を見れるようにし、
外部からアクセスできれば、状況と分析が両方できるようになる。
さて、作成手順と、つまずいた内容をメモ。
1 Catalystでひな形作成
2 ネットで取ってきたWEBテンプレートを、rootへ
3 DBの設定
DBIC::Schemaを利用。
4 root.pmのコーディング
つまずいた。
Responseへの参照と直接Hashとごちゃごちゃになってしまい、
余計な時間を費やした。
DBIx::Class::ResultSetを良く読むべし。
5 ttの作成
ひな形から改造するだけ。
30分くらいでできた。
月: 2010年10月
続:The old Moose::Util::MetaRole API (before version 0.94) has been deprecated
先週、タイトルのエラーについて書いた。
CentOSのUpdateを行ったことで、Perlのバージョンがあがり、
それに対応するためにCPANしたら、Catalystのバージョンなどがあがり、
結局、タイトルのエラーが残ってしまった。
今日は新しいプライベートシステムを作るのに、
CatalystでCreateしようとおもったら、やはり出てくるので、
原因を突き止めることにした。
と、いっても結構あっけなく見つかった。
Catalyst::Controllerの10行目。
use MooseX::MethodAttributes;
と、あるので、もしや・・と、
MooseX::MethodAttributesを、CPANでUpdate・・・
エラー消えた(–;
なんともあっけない。
CatalystのUpdateの時に勝手にかかってほしかったです。
動きが少なくシストレ向き・・
今週はシステムトレードには都合の良い、
安定した動きでした。
ただ、この安定した動きは、動き方が少ないだけで、
嵐の前の静けさというところでしょうか。
すこしの力のひずみで大きく変動しそうな気がします。
すこし本番が怖いですね・・。
941,926 => 1,006,687 +64,761
The old Moose::Util::MetaRole API (before version 0.94) has been deprecated
Catalyst起動のたびに表示される。
まー警告なので無視しとけばいいですけど、
毎回出てくるの気になる。
はやく、Catalyst対応してくれないかな・・。
Catalyst動かず
ここ2週間ほど腰痛がひどい。
そんなわけでこの週末は家でこもることにした。
うちのWebサーバのモジュールUpdateを最近していないことが気になっていたので、
この際Updateする。
yum update
で、一通りUpdateする。
Catalystで稼働しているサーバがあるので、再起動すると
weaken is only available with the XS version of Scalar::Util
とのこと。
Scalar::UtilがXSでないといけないらしい。
CPANから
cpan> look Scalar::Util
でディレクトリ確認。
$ perl Makefile.PL -XS
$ make
$ make test
$ make install
で、XSバージョンをインストール。
でも、それ以外にもいろいろと不具合がでてしまった。
ふーー
あまり安易にUpdateしない方がいいですね・・。
シストレには厳しい動き
今週も厳しい動きでした。
予測不能な動きが大きくて、シストレ向きではないですね。
平常時の動きでは利益を積み重ねれますが、大きな動きの時に
対応できずに、マイナスが大きくなってしまいます。
この動きに対応できる指標もありますが、そちらを選択すると、
平常時にうまく対応できません。
ほんと難しいです。
1,022,401 => 941,926 △80,475
クリック証券の余力表示
今日早めに帰りシステムを眺めていると、
どうもいつもと違う表示が・・・。
なんと余力表示がずれている。
画面を見てもよくわからず、ソースを見ていると、
「【追証未解消金額】」
なる項目が増えていた。
先週の金曜日にはなかったはずだけど・・・(--;
画面を勝手に変えられるとシストレには困るんですね。
なんとか利益確保
なんとか先週は利益確保できました。
全体的に大きな動きがあったにもかかわらず、
なんとか利益を確保できました。
大きな動きはありましたが、急速な変動がすくなく(JPYで1円を超えるような)
すこしずつ利益を積み重ねました。
1,000,000 => 1,022,401
+22,401
もう少し安定してきたら、本番処理入りたいですね・・。
9月分のシミュレーションが、スレッド数の割り当てをいつもより、
すくなくしたせいで、未だ終わっていません。
1月の結果を計算するのに10日かかっているようでは、すこしつらいです。
シミュレーションを少し見直さないといけないです。
とりあえず、毎週、週毎に計算をして、一月毎の計算は複数のPCを使って、
2日程度でできるようにしたいと思います。
最近は、XML関係のプログラムをさわってます。
最終的にはXBRLをデータベースに格納していきたいと思っています。
XMLDBは使い方もよくわからないので、とりあえず、
MySQLで管理しようと思っています。
必要なデータをRDBで管理して、XBRLもソース毎格納しようと思っています。
コンソールアプリの制御
以前に作業した内容であるが、
こちらにUPしていなかったので、
メモ的にUP。
Windowsアプリ開発(VisualC++6.0)で、
コンソールアプリをGUIから制御する必要があったので、
試行錯誤、コンソールアプリの処理結果を取得するだけなら比較的簡単だが、
リアルに制御しようとすると、ちょっと面倒だった。
と、いうか、いままで避けて通ってきた道なので、
一から勉強。
試行錯誤の結果はソースに反映されているので、
とりあえず、作業中のメモからキーワードを抜き出し。
・コンソールアプリをDialogを起動して作業するなら、モードレスダイアログ。
モーダルダイアログはメッセージの処理が面倒。
・コンソールアプリの起動。
CreateThreadで起動したスレッドから、CreateProcessでコマンドを実行。
・コンソールアプリとのやりとりはPipe。
Pipeを標準入出力と結びつけて処理。
・Pipeの処理は入力、出力ともにThreadで処理。
・データの受け渡しは、グローバル変数でOK。
普通にグローバル変数で制御OKだった。
スレッドの制御はint型のSwitch。
やりとりはCString型の文字列。
文字列のやりとりには、LockBufferでブロックの処理はしとく。
しないと文字列がぐちゃぐちゃになる。
と、言った感じ。
また不明点などあれば、コメントでもいただければ。
口座閉鎖で中途半端に終了
今週は気が付かないうちにデモ口座が閉鎖されていた。
期限が一月になってから、週の途中できれてしまうことが多いです。
ただ、一月単位でみれるので、検証という意味では都合が良いです。
最終週は、
822,261 => 672,013 で、△150,248
でした。
うーーん、最近のこの動きは、かなりつらいです。
ここしばらくは、このようにつらい時期かと思いますが、
検証としては、十分に材料となりますので、
がんばって稼働していきたいと思います。
今週月曜日から9月分のシミュレーションを開始して、
現在最終段階まできているので、間に合えば、新しい指標で、
来週から行いたいと思う。
今回から最適指標を抽出するシステムの仕様を変更している。
シミュレーションの結果を分析するのは現在過去1年分を分析しているが、
結果の比重を、最近になるほど重たくなるようにした。
昔も同じようなことをしていたが、最近は分析に時間がかかるので、
決まった期間で処理するようにしていた。