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

今日は、FX相場が動いている。
うちのシステムも、今日の朝から稼動させていた。
クリック証券から、８時過ぎまで順調にレートも取得しながら、仕掛けを行っていた。
ただ、生データを見ていなかったので、８時半くらいに確認すると、
なんと・・、取得レートのSの数字が妙に丸まっている。（下４桁が０）
生のデータを確認してみると、
なんと！！
８時７分からページのレイアウトが変わっていた(^^;
普通、メンテ終了後とかから変えない？
と思いながら、１時間くらいかかりながら、
新フォーマットに対応完了。
念のため、株.comも確認したが、こちらは以前どおり、
お行儀よく取得できていた。
レートの単位が違うから、取引の途中にレートの取得先変えるのは、
心配があるので、なんとか、違うところからもうまく取得できれば
いいんですけどね。
やはり、本番処理は、５日以降くらいに実施します。

本年もよろしくお願いいたします。
さて、今日はシステムの年送り作業を行った。
うちのFX取引システムは、10コほどのシステムが連携して動いている。
その中で、稼動している年を決めうちしているシステムがあった。
過去の記憶を基に、作業をしてみると、去年に年送りをしなくても、
当年の処理になるように修正されていた。(^^;
去年のメモには書いていなかったので、覚えていないが、
プログラムソースには、直した痕跡が残っていたので、
間違いないだろう。
今年は３日から取引が始まるので、実際の稼動を見ながら、
実際に年送りできているか検証したい。
年送りではないが、先ほどから、去年の12月分のシミュレーションを
開始している。
また１週間以上かかるので、実際に指標を選ぶのは10日くらいになると思う。
なんとか、週毎の計算結果を、土日できっちり指標を出したいんですけどね・・・。

先日書いたシステムの監視と検証。
監視という意味で、現在のシステムの稼働状況だけでなく、
現在の口座情報も表示しようとプログラムを書く。
コーディングは簡単にできたが、実際に動かすと二重ログインで、
クリック証券からはじかれる。
どうも、Catalystでネットアクセスする時に、
接続のたびにモジュールを初期化しているはずが、残っている模様。
しかも、あまり頻繁にチェックすると、取引システムの接続でエラーがでてします。
と、いうことで、このロジックは削除しました。
取引システムで残高チェックをしたときに、
データベースに情報を保存して、その情報を参照するように修正しようと思う。

定期的に指標の見直しを行っていることは、以前から書いている。
ここのところMySQLで蓄積している、シミュレーションの結果を、
Accessでリンクして検証している。
当初は修正が楽で、見やすいと思っていたが、数字の羅列だらけで、
読み切るのに時間がかかる。
その結果、指標の見直しが、２，３ヶ月に１回になってしまい、
折角のシミュレーション結果が、リアルに生かせていないと感じていた。
Accessでなんとかできないかと思ったが、グラフを作ったり、
分析を縦横無尽に行うには、どうもAccessの動きが鈍くて、
見るに堪えない状況になった。
結局数年前に検討した、Webアプリ化するのが、一番楽だということで、
今日から作り始める。
折角なので現在のシステムの稼働状況を見れるようにし、
外部からアクセスできれば、状況と分析が両方できるようになる。
さて、作成手順と、つまずいた内容をメモ。
１　Catalystでひな形作成
２　ネットで取ってきたWEBテンプレートを、rootへ
３　DBの設定
　　DBIC::Schemaを利用。
４　root.pmのコーディング
　　つまずいた。
　　Responseへの参照と直接Hashとごちゃごちゃになってしまい、
　余計な時間を費やした。
　　DBIx::Class::ResultSetを良く読むべし。
５　ttの作成
　　ひな形から改造するだけ。
　　30分くらいでできた。

以前に作業した内容であるが、
こちらにUPしていなかったので、
メモ的にUP。
Windowsアプリ開発（VisualC++6.0）で、
コンソールアプリをGUIから制御する必要があったので、
試行錯誤、コンソールアプリの処理結果を取得するだけなら比較的簡単だが、
リアルに制御しようとすると、ちょっと面倒だった。
と、いうか、いままで避けて通ってきた道なので、
一から勉強。
試行錯誤の結果はソースに反映されているので、
とりあえず、作業中のメモからキーワードを抜き出し。
・コンソールアプリをDialogを起動して作業するなら、モードレスダイアログ。
　モーダルダイアログはメッセージの処理が面倒。
・コンソールアプリの起動。
　CreateThreadで起動したスレッドから、CreateProcessでコマンドを実行。
・コンソールアプリとのやりとりはPipe。
　Pipeを標準入出力と結びつけて処理。
・Pipeの処理は入力、出力ともにThreadで処理。
・データの受け渡しは、グローバル変数でOK。
　普通にグローバル変数で制御OKだった。
　スレッドの制御はint型のSwitch。
　やりとりはCString型の文字列。
　文字列のやりとりには、LockBufferでブロックの処理はしとく。
　しないと文字列がぐちゃぐちゃになる。
と、言った感じ。
また不明点などあれば、コメントでもいただければ。

この年末年始は、ひたすらＦＸシミュレーションを繰り返していることと、
来週から月末まで（３週間ほど）出張で遠出する準備（主にPCの環境）のために、
時間がとれずにサーバの構築はさわることができなかった。
出張に出てしまうと、今のような午前様仕事ではなくなると思うので、
もう少し、作業が進むと思う。
今日は明日の仕事の準備が終わり、就寝までの時間で、懸案事項だった
「CatalystをApacheで動かす」作業をした。
今まではテストだったので、Catalyst付属のWEBサーバでよかったが、
今度の出張から帰ってくるとある程度、使えるものができている予定なので、
その環境を整備したかったからだ。
うちの環境はほぼリモート作業で設定することが多いことから、
設定関係はwebminで行っている。
WEBを見てみると、ほとんどが手でhttpd.confを直にさわっているので、
なかなか、なじめずに時間がかかってしまった。
結局は、webminからconfを直接さわってしまった。
（初めからそうしてれば早く終わったのに・・）
まだ本格運用でないので、ポートで切り分けることにした。
外部は80ポートのみ開放しているので、外からみることができない。
とりあえず、2900を使用するconfを書いた。
NameVirtualHost _default_:2900
<VirtualHost _default_:2900>
DocumentRoot /home/hoge/huga/root
PerlOptions +Parent
PerlSwitches -I/home/hoge/huga/lib
PerlModule TestApp
<Location />
SetHandler perl-script
PerlResponseHandler TestApp
</Location>
</VirtualHost>
と、こんな感じになった。
結構紆余曲折があったんですけどね(^^;

今日は昼から雑多なPC用務をこなした。
PCにたまった地デジデータのmpeg変換や、
FXシステムのシミュレーションデータの整理・・
それらの作業と平行して、mini1000に入れてあるCatalystで
MySQLを使うためのモジュールを入れる。
WEBなどを見ていると、CPANでモジュールを入れるだけのように思えたが、
なぜか全然入らない。
根本的なモジュールから呼ばれているモジュールが、手でforce入れしないと入らない。
結局、いろんな作業と平行してだけど、半日かかった(–;
なにやってんだか・・・。
Catalystで作りたいWEBが３種類ほどあるので、
とりあえず、小さなものから作っていきたい。
それにしても、Catalystの情報って少なすぎ・・・
時間空いたらまとめてUPします。

以前に書いたとおり、クリック証券からのレート取得システムで、
まれにレートの取得漏れが発生していた。
どうもレートを取得した後、データベースに格納するまでの
ロジックで、まれにうまくいかずに取得できないことがあることが
判明した。
先週末にプログラムを修正し、今週は新プログラムで取得した。
その結果、履歴の取得もれはなくなった。
原因は、Perlの数値と文字列の扱いが自由すぎたことへの甘えであった。
数値として計算したものを、文字列として加工していた。
従来はこれでうまく動いていたが、取得するページがすこし変更になり、
そのわずかな変化が、Perlの数値文字列変換に影響したようだ。
ちゃんと数値文字列を管理しとけばそんなことにはならなかったんですが・・

こちらで何度も書いてることですが、
最近新調したPCはマルチコアなPCばかり。
シングルCPUだった、AcerPower1000やgatewayのノートPCも
無理矢理CPUを換装してDual化している。
そんなわけでチカラワザのうちのシステムを効率的に動かすには、
マルチスレッドで並列処理をさせてやる必要がある。
今まではマシンの性能やネットワークの種類（有線or無線）などで、
実行するプログラム数を変えていた。
最初に稼働させてしまうだけであれば、良いがシミュレーション等の
最後の方の処理がある場合には、手作業で作業を分担するのは面倒である。
先週のシミュレーションが時間のかかったのは、この辺の事情がある。
そんな訳で処理の一部をマルチスレッド化することにした。
Perlでのマルチスレッドはいくつかの方法があるが、
今回は以下のモジュールを使用して、マルチスレッドにした。
自分的には今の環境には一番良いモジュールを選択したと思っている。
各モジュールの使い方などは、他にいろいろとページもあるので、
そちらに譲ることとする。
（自分の手書きメモには書いたけど、おこす時間がないです(;;)）
使ったモジュールは、
threads
Thread::Queue::Any
を使った。
threadsは定番。Anyは最初に処理したい内容を配列に格納して、
各スレッドがdequeueで取り出しながら処理することにした。
終了の判定がうまく動かないけど、処理自体はかなりきれいに処理をしてくれた。
これからは、どんなパソコンもマルチコア化していくだろうし、
これからのプログラムは積極的にマルチスレッドを使ったものを作りたい。

先日書いた「効率的なフィルタの設置」について考えた。
多くのストラテジーから自動的に利益額が大きく、効率的なものを探すためのシステムは
以前から稼働させているが、最終的に運用に使うために、そのストラテジーに、
フィルタをかけて稼働させている。
フィルタをかけることによって、資金効率を向上させたり、損失のリスクを回避させたり、
また、取引回数を減らすことにより、発注システムへの負荷を減らしたりできる。
今まではこのフィルタを、分析した結果を見ながら、手作業で設定していた。
分析結果は、平面的な分析結果のかたまりであり、実際の運用では立体的な分析が必要になる。
今までは平面を組み合わせて、立体的なフィルタを思い描いていたが、
どうしても、誤差が出るし、なにより時間がかかりすぎる。
そんなわけで、このフィルタを自動的に計算して、最適なものを選べるように、
あたらしくシステムを構築した。
システムと言っても、シミュレーションの結果はDBに格納されているので、
それを縦横無尽に集計しなおし、その結果をDBに格納すれば良い。
あとは、この集計結果を、OOOで分析すれば、かなり効率的に最適なフィルタを
選び出すことができる。

実際に稼働させてみて、分析をしてみると、おもしろいことがわかった。
フィルタのかけ方で、平面的に分析したものとは、まったく違う組み合わせが、
実は一番高い利益を出せたり、思いがけないフィルタで、効率的（平均利益が高い）なものが
できることがわかった。
実際の稼働にいきなり使いたいが、やはり、ここは、すこし我慢して、再度、
デモトレードで見極めたいと思う。