月: 2011年5月

前にも書いたが、YahooNewsからデータを取得して、
定時にメール配信している。
今週月曜日から配信されなくなり、
今日原因を解明　=>　修正した。
原因は、
・RSSがZIP圧縮されて配信されるようになった。
・階層が変わった。
と、いうことで、それぞれ修正。
（わかるまで結構時間かかりましたけど）
メモリ上でのUNZIPは、
Compress::Zlib
を利用。
階層の解明は、
Data::Dumper
を利用。
やはりPerlからは離れられないです。

開発環境が、VisualC++6.0からVisulaStudio2010に変わったことを書いた。
基本的なMFCがかなり大きく変わっていて、便利になったのはいいけど、
かなり設定などが変わった。
その一つにメニューの表示がある。
昔のメニューは全て表示するのが当たり前だったが、
最近(?)は使わないメニューは表示しなくなり、なんどか使っていると、
最初から表示するようになる。
今作っているソフトは、メニュー項目が消えると困るので、
リソースなどを見たり、CMenu（すでにこれをみてる時点で古い・・）の
メンバをみたりしていた。
ネットでぐぐってみたりもしたけど、あまり情報がないままに、
ソースをみていると、それらしきコードが・・・。
CMainFrame OnCreate で、SetBasicCommandsへの
リスト登録。
なにやら基本メニューの登録らしく、
ここにメニューIDを登録しとくと、いつでも表示してくれる。
やれやれ。

先日の書き込みのとおり、このGW中に指標を変えた。
変えた時に若干のマイナスだったのが、
週が終わればかなりの赤字。
タイミングが悪かったとも言えるが、
結果としてはかなりきつい。
シストレは、最低でも一月単位で見ないといけないので、
今月末までは、この指標でがんばりたい。
1,000,000　=>　938,176　　△61,824

今日はGWのなか日ということで、
会社から強制休暇を言い渡されました。
（有休の消化割合が悪いため(^^;
　もっと休ませてくれてもいいのに・・一日だけとは・・）
今日は以前から気になっていた株式の整理。
先の震災から二月が経とうとしています。
なにより悪いのは、状況が分かってきているのにも係わらず、
先行きが見えないこと。
株価はある程度戻してきていますが、今の状態のまま保有するのは
すこしリスクが高すぎると思っています。
そして、今日の昼過ぎに、思い切って全て成り行きで売却しました。
成り行きだと、かなり、スリップするようになったんですね。
昔はそんなにスリップしなかったですが・・。
結局想定より、2万程余計に損失が出てしまいました。
予定では、この３末決算の配当で損失が相殺されて、
年収支はトントンになるはず。
それと、ついでに「牛」も売りました。
前にも書いたかもしれませんが、牛投資を10年くらいやってました。
毎年配当が5%くらいつくので、保有していましたが、
投資先として、リスクとリターンを考えると、リスクが上回ると判断しました。
今回の処分で、リスク商品は一旦引き上げとなりました。
（そういえば、国債がありました(^^;）
5/7追記
当初、上記で若干の損失が出ると書きましたが、
今日見てみると、トントンになっていました。
譲渡した当日は譲渡益税が引かれた状態になっているんですね。
マイナスの銘柄があり、結果的に譲渡益税が引かれずに、
損失が縮小しました。
あとは５末の配当が入れば、収支がきまります。

前回の指標の改定は・・
ノートを見ると、去年の９月。
半年どころか、８ヶ月も経っていた。
世界の経済情勢などが激しく変わる中では、
８ヶ月は長すぎる。
せめて３ヶ月程度で改定できるようにしたい。
今日は一日かけて指標を作っていた。
一日と言ってもずっと作業をしていた訳でなく、
・アクセスへのデータの取り込み
・アクセス上での検討
・エクセルへのエクスポート、
・エクセルでの検討・・・
と、ベタな作業が中心であった。
また、待っている時間が結構あった。
いつもは３つの指標で取引をしているが、
今回検討した中では、どうしても３つ目がみつからず、
結局、２つでの運用となった。
今回は、EUR_USDとEUR_JPYの２指標。
積極的に攻めるパターンと、相場が暴れている時に仕掛けるパターンの２つになっている。
この１，２週間様子をみて、本番モードも参入していきたい。

先日から何度か書いているが、
やっとシミュレーション結果の分析をしている。
基礎データは毎週計算結果を追加。
月に一度は分析用DBの更新作業をしているが、
今回は分析用のDBを駆使して、最適な指標を作る作業を
手作業で行っている。
いつもは半自動で作業しているが、作業内容の検証も兼ねて、
SQLサーバの補助として、アクセスとエクセルを併用しながら、
内容を検証している。
その中で、レコード数が妙にすくないテーブルがあったことから、
手作業で再度集計してみると、やはり少ない。
そこで、再度、分析用DBの作業をやってみると、
「The total number of locks exceeds the lock table size」なるエラーが出ていた。
結局はメモリ不足ということで、
MySQLのinnnodb_buffer_pool_sizeを、512Mくらい割り当てて作業を再開。
Linuxの方では問題なかったが、Windows用Mysqlは微妙にその辺の頑丈さが
違うようです。
いつもは、FX取引用サーバの空き時間を使って作業しているが、
かなりの負荷をかける作業をするので、作業DBをWindows上で行ったのが原因。
同じ４Gのメモリを積んでても、メモリ管理などが違うので、使うソフトに応じて
かんがえていかないといけない。