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

イートレへのログインチェックをする。
今まで、ベタベタにソースにチェックするロジックを書いていたが、
今回はイートレの取引関係をパッケージにしているので、
ちゃんと、Check_Loginという関数を作った。
イートレへリクエストを出すと時間がかかるので、
寸前の状態を取得して、そのhtmlにログアウトボタンがあるかで判断した。
試運転ではちゃんと動いてそう・・・。
明日からは、実際の発注部分を書いていきたい。
ざっとhtmlをみた感じでは、「取引」ボタンから、フォームに必要項目を入れて、
Submitしたらいけそうな感じである。
単純な作業なので、すこし手間がかかるかもしれないが、
ちゃんと作っておかないと、テスト＝本番なので、こけると怖いので、
慎重に作りたい。
（単位とか、金額間違えるとエライことになりますからね(^^;）

昨日は、取引状態をチェックして、取引の判定をするところまで構築が進んだ。
今日は、実際に取引をすべきかの判断をし、そこから注文の発注をする部分までを考えた。
実際に取引をすべきか、については、
日中足データの現在価格　＜　要処理精査テーブルの買付限界価格
の、場合には買い注文を入れることになる。
ここは、データベースから情報を取得し、判断するだけである。
問題は実際の注文処理。
これは、以前の日中足データをイートレから、気配値などを取得するときに、
イートレへのログイン、証券コードの入力、現在値等の取得、までは作成している。
前回は、プログラムにそのままサブルーチンとして処理していたが、
今後開発するシステムは、イートレへの注文や確認が多くなることから、
パッケージ化することにした。
Perlでのパッケージは、関数等の部分を別ファイルにし、
packageで宣言
関数サブルーチンが使っていたグローバル変数を引数化
すればすむ話である。
そんなに難しくない。
とりあえず、外部パッケージ化した、日中足データ取得システムは
無事動作することが確認された。
次に、本来の目的である、注文処理であるが、
これは時間切れ・・・・
実際のプログラムは明日以降として、
とりあえず、ログイン状態かどうかの検証関数を考える。
ログイン前とログイン後のページがそっくりなので、
判定が難しい・・・
おっ、ログイン状態の時は、「ログアウト」ボタンができている。
（当たり前だが・・・）
とりあえず、これを基に判断したいと思う。
そうそう、今回はパッケージ化だが、最終的にはモジュール化したい。
一般に公開するのはどうかと思うが、今後同じようなシステムを作るときに、
楽にできそうだし・・。

木曜金曜と出ていたので、今日は休息日ということで家に居た。
そんな訳で、久しぶりにまとまった時間でプログラムを組むことができた。
以前から構想でつまづき、なかなか進めなかったが、思い切ってプログラミングしていくことにした。
（いつも、後で後悔するんですけどね・・・(^^;）
今日は、
・　日中足データの更新タイミングを検知
・　取引区分（Swing買・売・デイトレ）に応じて処理の分岐
・　銘柄の取引状態（要監視・約定待ち・精算監視）に応じた分岐
・　個別の判定処理の入り口
と、いったところである。
すべてデータベースを参照しているので、エラー処理などをいれると結構めんどくさい。
（ほとんどはサブルーチン化してるんですけどね）
その中で、存在は知っていたけど、今まで使うのを躊躇していた関数をつかった。
「selectrow_hashref」である。
使っている人は使っていると思うが、私は怖くて今まで、
ｐｒｅｐａｒｅから順番に辿っていたが、取得にそんなリスクがないものは、
良いかと思ってつかってみた。
これは楽ちんである、変数を使う感覚でデータベースにアクセスできる。
Perlとの相性もいいし・・、ちなみにソースは、
sub GetSeisaAll($){
my $keycode = shift;
my $sql = “SELECT * FROM kabu.seisa s where code = $keycode”;
my $all = $db->selectrow_hashref($sql);
((エラー処理))
foreach (keys(%$all) ){
print STDERR $_ . ‘:’ . $all->{$_} . ” “;
}
return($all);
}
と、こんな感じで、ハッシュに入ってくれる。
明日は時間があるかわからないが、できれば、
スイングの買いを監視して、注文を出せるようになればいいんだけど・・

ヤフーファイナンスへのリンクを作成しました。
今朝方早朝にこちらのBlogにRESをいただきました。
「コピペでなくて、直接リンクした方が使い勝手が良いのではないか」
と、いう貴重なご意見でした。
ねずみおとこさん、ありがとうございました。m(__)m
よく考えると、MyYahooにコピペでも５０件の制限があるので、
1Clickの方が断然楽です。
そんなわけで、今日は早めに会社を切り上げれましたので、作ってみました。
最初に「いつもの一覧」「コードの羅列（コピペ用）」「ヤフーファイナンスへのリンク」の、
順番で作成しました。
リンクについては引数が５０件を超えるとエラーになるので、最初から５０件だけをURLと
するようにしました。
実はこの一連の表は、awkで作っているのですが、
なんと、1Lineで書いてます。
すごい横に長いです(^^;
そろそろ外部ファイルにしないといけないかな・・・

自動投稿成功しました。
今日は早く帰宅できたので、早速チェックしましたら、
やっと、自動投稿できたようです。
これで明日からはUP作業は気にせずに、
システム開発に集中できます。(^^v
でも、今日は一銘柄のみ。
今週末にはシミュレーションをやり直して、
最近の動きを反映させていきたいと思います。
（シミュレーションも自動化しよ・・・）

自動投稿失敗しました。
午後５時半になっても携帯に通知がこないので、
どこかでおかしかったんだな・・・と感じていました。
原因は、cronでの起動スクリプトの中に、コマンドをフルパスで記述できていない部分が
あったということでした。
基本的な過ちです(–;
先ほど修正をして実行してみました。
で、その時に、データベースの出力そのままでは見にくいので、
タグを付加してテーブルで表示するようにしてみました。
もう少し早くしとけばよかったですね。
今晩は、自動売買の部分を作成できればと思います。

今日の自動投稿のシステムで、一番時間のかかったのは、
実は、「ココログ対応」であった。
ココログには、メールでの投稿ができる（当たり前ではあるが・・）。
それを利用して投稿するのであるが、
・日本語コードをうまく認識してくれない。
・カテゴリーの指定ができない。
・お行儀の良いメールでないと受付してくれない。
と、いろいろと問題があった。
・日本語コードをうまく認識してくれない。
　結局、nkfでシフトJISに投稿する内容を変換して、
メールヘッダの、Content-typeに、Shift_JISを指定して認識させた。
当たり前の書き方であるが、今までメールでいろいろと通知させるシステムを
作っているが、ここまで書いてあげないと日本語を認識しないのは、珍しい・・(^^;
・カテゴリーの指定ができない。
　FAQではあるが、メール投稿では、カテゴリーを指定できない。
デフォルトで、投稿先などを設定する項目があるのであれば、
デフォルトのカテゴリーの設定してもおかしくないのであるが・・・
なんでしないんだろ・・・
・お行儀の良いメールでないと受付してくれない。
そのほか、メールヘッダはお行儀がよくないと、
受付できない旨のメールが返信される。
しかも、英語で１行だけのエラー・・・こんなの・・
The secret email address must be in To, Cc, or Bcc
英語読めない人もいるし、日本語でエラーを返さないと、
もらった方は意味がわからないかも・・
ブログは基本的にお手軽に専門知識がなくても投稿できるのが、
メリットのはずなのであるが。
今、思えば、最初からお行儀良くやっておけばよかったのであるが、
今までの、「これくらいしとけば、あとはやってくれるだろ」との思いが、
時間のかかった原因であった。
ココログに関しては、最初からきちっと対応したい。

久しぶりの更新になってしまった。
Blogでこんなに更新空いてしまったら意味ないのであるが、
仕事の方と体調不良のため作業がなかなか進まない。
今日は土曜日ということで、合間を見て作業を行った。
また、シグナルも出力してみた。
まず、今日完成したのは、日足データの取得。
なぜ、今さら・・・という感もあるが、今までは履歴から取得していたので、
特に不自由もしなかったので作成が後回しになってしまった。
ただ、毎日の更新を考えると当然に必要な機能である。
今、3900銘柄を管理しているので、過去履歴で１日を取るのと、
最新の値だけをまとめて取得できるのでは、効率が全くちがう。
作成は例のごとくPerlで作る。
内容は特に難しいものはない。
また、取得は１回のリクエストで５０銘柄とした。
ただ一つ、いままで通りで動かない部分があった。
それは、日本語の処理である。
Yahooはご存じのとおり、EUCで書かれている。
EUCはUNIXには非常に都合の良い文字コードであるが、
PCレベルではShiftJISな方が読める環境が多い。
そこで、今回はシステムはすべてソースコードをShiftJISに統一している。
そんなわけで、htmlソースは、
EUC => UTF16 => SHIFT_JIS
と、変換して処理している。
以前はjcode.plというので処理していたが、Encodeで処理するようになり、
最近、Jcodeが更新されたので、Jcodeに戻っている。
おかげで、今まですこぶる快調だったのだが、今回はどうしても止まってしまう。
どうも、一覧で取得する場合に、特定の文字コードが邪魔をしているようである。
結局、
$jconv->set( $a->content() )->euc;
$tree->parse( $jconv->sjis );
と、していたところを、
$tree->parse( Jcode::convert( $a->content(), ‘sjis’, ‘euc’ ));
と、して解決した。
やってることは全く同じなんですけどね・・。
直接変換しているようでも、内部ではutfで処理してると思ったんですけどね・・。
とりあえず、動いたので良いことにします。
今回の、日足データ取得で、毎日早い時間にシグナルを出すことができるようになる。
早速計測。
日足データ取得（全銘柄）　　３分
指標計算（必要分のみ）　　２分
シグナル計算（必要分のみ）　３分
シグナル抽出　　　　０秒
全部合わせても１０分かからないですね。(^^v
これなら、昼の間に２０分遅延で処理しても、後場までには十分計算できそう。
半日足データでシグナルを出せるともう少し精度が上げられるかもしれない。
そんなわけで、相変わらず意味がないかもしれないが、
本日のシグナル。
+——+————+———–+———–+———–+——-+——-+
| code | date | point_max | point_avg | point_min | rieki | kikan |
+——+————+———–+———–+———–+——-+——-+
| 1914 | 2006-05-26 | 100 | 100 | 100 | 12 | 25 |
| 9717 | 2006-05-26 | 100 | 100 | 100 | 68 | 8 |
| 9621 | 2006-05-26 | 100 | 100 | 100 | 49 | 17 |
| 7201 | 2006-05-26 | 100 | 94 | 85 | 66 | 29 |
| 5233 | 2006-05-26 | 100 | 98 | 97 | 8 | 10 |
| 5196 | 2006-05-26 | 100 | 99 | 98 | 18 | 6 |
| 4921 | 2006-05-26 | 100 | 100 | 100 | 251 | 25 |
| 4186 | 2006-05-26 | 100 | 100 | 100 | 64 | 25 |
| 9731 | 2006-05-26 | 100 | 100 | 100 | 14 | 20 |
| 3337 | 2006-05-26 | 100 | 100 | 100 | 85 | 15 |
| 2730 | 2006-05-26 | 100 | 100 | 100 | 85 | 6 |
| 2578 | 2006-05-26 | 100 | 100 | 100 | 21 | 13 |
| 9479 | 2006-05-26 | 99 | 99 | 99 | 5110 | 5 |
| 9475 | 2006-05-26 | 97 | 89 | 80 | 122 | 27 |
| 6440 | 2006-05-26 | 96 | 95 | 95 | 10 | 5 |
| 9715 | 2006-05-26 | 96 | 95 | 93 | 138 | 5 |
| 9003 | 2006-05-26 | 96 | 92 | 90 | 17 | 66 |
| 1972 | 2006-05-26 | 94 | 87 | 84 | 16 | 6 |
| 8194 | 2006-05-26 | 94 | 93 | 93 | 79 | 7 |
| 3106 | 2006-05-26 | 93 | 91 | 89 | 8 | 19 |
| 4634 | 2006-05-26 | 93 | 93 | 92 | 19 | 19 |
| 4042 | 2006-05-26 | 93 | 87 | 84 | 10 | 7 |
| 8234 | 2006-05-26 | 92 | 85 | 64 | 34 | 7 |
| 1964 | 2006-05-26 | 92 | 91 | 91 | 7 | 6 |
| 7447 | 2006-05-26 | 91 | 70 | 50 | 183 | 13 |
+——+————+———–+———–+———–+——-+——-+
25 rows in set (0.01 sec)
いつものごとく、この情報をもとに取引されても自己責任でよろしくお願いします。
ちなみに私はまだ取引してません(^^;
早く自動売買作らないと・・

風邪はだいぶましになったが、まだ体調は万全とはいえない状態。
こんな時期に風邪とは情けないが、会社でも結構はやっているようで、
仕方ないとあきらめる。
さて、先日までは、シミュレーションの結果はテキストファイルに出力していたが、
（厳密にはSTDOUTだが・・・）
後々のためにデータベースへの格納をすることにする。
その前に、先日の不具合を先に修正する。
・利率計算が微妙におかしい
　ロジックをみると、やっぱりおかしい・・・、すぐになおした(^^;
・DIV0エラー
　ロジックを見てもおかしくない。
　そもそも639銘柄も実行して止まったので、普通の状態ではない。
　メモリの関係か・・・と、悩む前に、
　基になる、指標データを眺める、6453をみてると、微妙に動きのない時期が・・・、
　そう、この１月ほどほとんど動かない時期に、ボリンジャーバンドの指数が０という瞬間があった。
　こんなこともあるんですね・・。
　とりあえず、セオリーどおり、割り算の分母は０判定をしましょう。
エラーがなくなったところで、データベースへの格納。
この辺はPerlのDBIでさくっと作る。
試行錯誤を軽くして、あっさり動作した。
なんとなく、テキストで見たときより、レコード数がすくないような・・・。
テストは明日の朝からにすることにして、
とりあえず、今日は寝る・・・・

なんとか、シミュレーション開始できそうになった。
先日は、ポイントの異常数値に泣かされたが、
今回は、ポイントが一定数以上になったときの判定で、
初歩的なミスをしていたことから、なかなか先に進むことができなかった。
26,244通りのポイント計算のパターンをシミュレートするが、
その時の、ポイントの割り振りをするところで、初歩的なミスをしており、
いろいろと、処理を進めると、MAX１００の数値が、１００を超えてしまい、
シミュレーションが異常なことになっていた。
今回、その原因がわかったことから、シミュレーションでのシグナルが、
だせるようになった。
今後はとりあえず、そのシグナルが最初に出た時に、売りor買いをする。
翌日の寄りつきで約定したものとする。
その後の高値or安値ー５％程度で反対決済をする。
実際の取引は、ザラ場を監視して、注文をだすが、とりあえずは、
こんなシミュレーションで、最適な指標の組み合わせを作りたいと思う。
ＧＷは暦通りなので、１，２は仕事であるが、残りの（5-2）連休を活用して、
今週中には、全銘柄のシミュレーションを終えたい。
来週は、手決済で実際にシグナルが出た銘柄を売買してみたい。
（実際に自分でやってみないと、本当の検証にはなりませんからね）