カテゴリー: プログラミング

今さらであるが・・・
Perlのモジュール内での関数呼び出し。
モジュール内では関数の最初に当然に、
sub kessai{
my $self = shift;
my $hiki = shift;
}
などとする。
なので同一モジュールで呼び出しをするときに、
kessai(undef,$_)
などとしていたが、どうも、すっきりしない。
WEBでしらべてみると、
__PACKAGE__->kessai($_)
と、するらしい。
なるほど・・と言う感じであった。

先日からクリック証券のWEBからレート情報の収集をしている。
当初は10分程度で止まってしまったが、
現在は３日停止せずに動作している。
やはり実際に動かしながら検討していかないといけない。
ところで先日デモ口座にログインしたところ、
注意として「頻繁にログインを繰り返す人は強制排除します」というお知らせが
UPされていた。
機械的にトレードをするためにテストをするのはいいですが、
ちゃんと動くまでは挙動をちゃんと監視しておかないと、
強制排除だけでなく、他のひとまで排除されてしまいかねないので、
プログラムを組む人は、稼働しているかを確認しながら、順次処理を追加してほしい。

今週はクリック証券からのレート取得を続けている。
当初の予想より順調に取得できている。
当初は10分位で落とされ、どうなるかと思ったが、
現在は24時間は継続して取得することができるようになっている。
なぜか午前４時に落とされると、再ログインで失敗している。
おそらくなんらかの制限を加えているものと思われるが、
重要な時間帯なので何とか取得できるようにしたい。
今週末の復習シミュレーションは、専用PCと取引用PCの２台で行っているので、
22時くらいには終了できそう。
もう少しするとリアルシミュレーションの数を現在の300から450程度に増やすつもりなので、
もう少し効率的にシミュレーションできるように検討していきたい。
将来的には現在保有する18000の指標をリアルシミュレーションにかけて行きたい。

一昨日はデモ口座でレートの取得ができた。
かなり加工が必要であるが、Perlの強みでかなりすっきりと、
確実に取得できるようになった。
これでとりあえずは、デモ口座でAPIが停止されても、
クリックからのレート取得はできるようになった。
ただ、今までの経験で、デモ口座は取引時間中でも、結構お気軽にシステムを止める。
実取引はしないが、貴重なレート情報が抜けると、今後のシミュレーションに支障がある。
そんなわけで、昨日は本番口座でのレート取得を試みた。
URLとID、PWを変更して・・・起動パラメータで切り替えできるようにして・・
と、お気軽に修正。
当然動かない(;;)
たしかに見た目は違うが、htmlソースを見てもシステム的に大きな違いはない。
これで結局はまってしまい、試行錯誤を繰り返した。
Mechanizeはかなり優秀なので、デモでは気がつかなかったが、
やはり本番口座はセキュリティの関係からか、動作がかなり違っていた。
結局、submitではなく、submit_formを使い、
その後、follow_linkでつないで事なきを得た。
その後のレート取得は、全く同じロジックで抜き出すことができた。
これからは、注文、決済を組み立てていく・・・
注文はいいけど、決済はかんり面倒そう・・、というかクリックに怒られそう。
なんか良い呼び出し方法はないのか(–;

今日の記事でも書いたように、
クリックは信用ならない状況ですが、
環境としてすぐに捨てるわけにもいかず・・
とりあえずAPIではなくWEB経由でのアクセスをするように修正をした。
もともと、株式関係、ひまわりなどはWEB経由で処理をしていたので、
コーディングは特に問題なかったが・・
デモ口座の入り口がわからずに時間がかかった・・
本番口座は「もばとれ君」http://www.click-sec.com/m/
があるのでこちらからアクセスすると処理をしやすいが、
デモ版ではこの入り口がない。
本番を「もばとれ君」、デモ版を「API」とするのが簡単だが、
デモ版もいつまでAPIがあるかわからないことから、
意地でもデモ版でWEBアクセスをすると思っていた。
結局試行錯誤でデモ口座の「もばとれ君」もどきの入り口を発見した。
「もばとれ君」とはすこし形が違うが、そこは仕方ないので、
これをもとにまずデモ版の取引をAPI同様にできるようにしたい。

今、人から頼まれてプログラムを書いている。
いつも自分で作るのは、MacやUNIX系なので、
C++よりもPerlやShellスクリプト、SQLでなんとかなる。
ただWindows上でプログラムを作ろうとすると、どうしても
VisualStudioを利用することになってしまう。
よくできた開発環境だと思うが、どうもわかりにくい、
変に親切なのが、変にプログラムを書く者からすると、
妙に使いにくい。
GUIのプログラムは、どうしてもコーディング量が増えてしまうので、
どうしても各開発環境の用意しているモジュールを使わないと、
手間がかかってしまう。
さて、今回は久しぶりに一からつくることになったので、
基本部分からコーディングしていく。
・書類を使うので、DocViewを使う。
・作るのに時間があまり猶予ないのでMFCで作る。
・画面は最初からスプリットする。
などを考えると、MFCのウィザードでDocViewでSplitterを使えば、
簡単である・・。
でもDocViewって、最初にTemplateを定義しないと・・
で、そこに二つのViewを登録できないし・・
CSplitterVieから派生させたクラスを登録して・・
などを考えていたが、どうも思ったものができない。
いろいろとするが、結局はもとのとおりとなった。
また同じようなものを作るときの参考にメモしておく。
まず、SDIでMFCスケルトンを作成。
CWinAppのInitInstanceで、CSingleDocTemplateするときに、
Viewの登録で適当なView（最悪NULLでも）を登録。
CFrameWndのローカルに、CSplitterWndのメンバ宣言。
OnCreateClientでCreateStaticして、
CreateViewを必要ペインだけView作成。
OnCreateClientの戻り値は、上の戻り値を返す。
派生元のOnCreateClientは呼ばなくていいです。
こんな感じで作れます。
Docのメッセージなどはそろぞれにいくみたい。
とりあえず、この雛形から作業進めていきます。
新しい環境ほしいけど、とりあえず、前に購入したのが
高かったし、慣れているので、まだ6使ってます。

今日も合間をみては、シミュレーション結果と
取引システムでの誤差について検討していた。
両方の取引履歴の出力をし、検討したところ、
約定のタイミングが３秒シミュレーションの方が遅くなっていた。
これは、実取引の場合、約定するまでに３秒くらいかかると思い、
設けた「間」だったのであるが、これが、結果的にトレード結果の差に
なっていることが判明した。
決済取引自体は両方とも同じタイミングでおこなっているので、
実際には差はでないはずである。
気持ち悪いのでその分の修正を加えた。
これで完全に一致したので、これから再度シミュレーションをやり直す。
ただ、いままでやってきたシミュレーション自体は、若干の数字の差は出るが、
無意味な結果がでてきたわけではないので、現在ある結果を基に検討をしていきたい。

今朝方、自動取得のシステムが、エラーを吐いていた。
「　passed as text_regex is not a regex　」となっている・・
たしかにfollow_linkで、text_regex指定をしているが、
なんで先週末まで問題なかったのに、いきなりエラーが出るのか・・
しかも、エラーと言いつつも、戻り値はundefでなく、
そのまま、HTML::TokeParserに渡せて、レートは取得できている。
とりあえず、会社に行き、定時にそそくさと帰宅して、
確認してみる。
HP側が変わっているようには見えない。
システムも変わっていない。
OSのUpdateも行われていない。
・・・
と、いうことで、原因不明である。
とりあえず、follow_linkの引数を、
text_regex => q//
を、
text_regex => qr//
にする。
当初、textにしていた名残の用である(^^;
でも今までは問題なくマッチしてたんですけどね。
原因不明ですが、とりあえず、動いているので良いことにする。
それと、qrで、utf8な２バイト文字をしていすると、やっぱりマッチせず。
うーーん、こちらも不明です(–;

この土日で取引システムの構築が思いの外、進めることができた。
春休み明けで、家族の疲労を解消するため、予定を入れなかったことから、
作業時間が確保でき、本業の仕事を片づけつつも、システム構築を進めることができた。
先週は、本番取引用システムの、シグナル発生ルーチンの検証が必要であることから、
本番取引用システムに、テストモードを追加した。（ややこしい・・(^^;）
実は、その前の週に本番処理用の検証で、実際の取引時間に併せて処理をしていたが、
決済用のシグナルが、うまく出ない時があり、ソースをいくら見てもわからない状況があった。
そこで、テスト用モードを追加したシステムを構築していたのであるが、
思いの外、作業に時間がかかった。
そのテストモードが、本日無事稼働し、シミュレーションで出た数字とほぼ同じ決済結果を、
出せるようになった。
今週は、実際の注文処理や約定照会の処理を追加するつもりである。
（時間がとれれば・・・ですけど(–;）

先日からソースコードのutf8化を進めている。
作業自体はそんなに大変なものでもなく、
・　ソースをutf8に変換（ｎｋｆ）
・　Jcodeで変換していた部分を、encodeに書き直し
・　出力部分にdecodeを入れる
と、いたって平和な修正で作業が進むはずであったが、
中にうまく動かないシステムが出てきた。
しかも、全然動かなければ対処のしようもあるが、
数百のループの後でおかしな挙動がある。
しかもその取得しているWEBページが一定でもない。
いろいろといじってみると、どうも、Mechanizeの返値が一定していないことがわかった。
原因はわからないし、追求していく時間もないので、結論だけ書くと・・・
MechanizeのGetで取得したページを、contentで参照したときに、
ＭｅｃｈａｎｉｚｅのGetの返値のcontentと、そのものが保有するcontentの文字コードが
違う・・・
今までは返値のcontentをTreeBuilderにparseしていたが、
そのもののcontentをparseすることで解決した。
しかも、このMechanizeの内部で、Getしてきたページのソースを、
Guessでencodeしているようで、decodeしてからparseすると、
はまります。
（だいぶはまってしまった・・・(–;）
これで、今まで懸案だった、シグナルを出せそう。