カテゴリ未分類 0
■■■■■■↓以下は凍結カテゴリー↓■■■■■■ 0
[KATS(自動売買プログラム)] カテゴリの記事
全87件 (87件中 51-87件目)
-
徹底的にテストしました。
・・・とタイトルに偉そうに書いてますが「出来る範囲で」です(^-^;今までほったらかしにしていた楽天RSS関係のテスト。まだそれっぽいデータを返してくれるようなテストサーバーは作って無いですが、ランダムなデータを返して色々なロジックを通させたり、0.1秒に1回ほどの高負荷な更新通知を発生させてシビアなマルチスレッド処理に耐え得るか等をテストしました。結果、至る所で「厳密には駄目」という処理が見つかりました。。。それらを潰し、やっとそれなりに動くようになりました。また異常終了の可能性についてもかなり低く抑えるように出来たはずです。ただ、上記のような高負荷ではマシンスペックが足りなさ過ぎてかなりの遅延が発生します。但しデッドロックではなく遅延なのでこれは仕方ない事だと思っています。なるべく無駄なロックはしないようにはしているつもりです。本番でどれほどの更新通知が来るのかはっきり分かってないのですが、遅延の起こり具合いによっては、例えば最悪「スレッド数が一杯の時は通知に対するイベント処理を間引く」などの荒業も必要かも知れません(苦笑)。だってPCが追い付かないんですから。。。・・・もっと速いPCを買えば済むんですよね(汗さて、明日の結果が楽しみです。売買ロジックに関しては、トレーリングストップの値を「一律1%」に戻しました。損切り額が減りますが利益確定が慎重になってしまいます。また、購入判断は先週より気持ちだけ厳しくしています。完全に話が飛びますが、今日はクリスマスですね。私は今から寝ますが、娘たちの勉強机の上にプレゼントを置くのを忘れないようにしないといけません。・・・まだサンタさんやってますｗ
Dec 24, 2007
コメント(8)
-
擬似楽天RSSサーバー
先日micorosoftさんから、非常に興味深いコメントを頂きました。私がNDdeのマニュアルを(英語だからという事もあり)斜め読みしていたせいなのですが、自分がDDEサーバーを比較的容易に作成出来るという事に全然気付きませんでしたし、「自作するんだ」という発想が全く思い浮かびませんでした。楽天RSS関係のテストについて今までは「この部分だけはザラバ中に実際動かさないとテスト出来ない部分だ」と言い訳し、テストから逃げていました。自分で思い浮かんだテスト方法は、DDEサーバー・・・というよりDDEクライアントのスタブやモックオブジェクト程度の発想でした。ソースを修正しないとテスト出来ませんので非効率ですし、あまりメリットが見出せませんでした。そう思って諦めていた楽天RSS関連のテスト。でもmicorosoftさんの「RSSフェイクサーバ」というコメントを頂いて目からウロコでした。まさに「なるほど！」でした。今日、改めてNDdeのヘルプを読み、DdeServerを試してみる事にしました。するとDdeClientの時と同様、サンプルソースを実行させてみるだけで大体の事が理解出来ます。思ったより簡単に擬似サーバーが作成出来そうです！サービス名を「RSS」に合わせておけば、マケスピ＋楽天RSSを実行する代わりに作成した擬似楽天RSSサーバーを実行させるだけでKATSからのDDE操作を肩代わりしてくれました。更新通知形式でもリクエスト方式でも、ちゃんと反応してくれます。但し実際の楽天RSSのように生きているデータを返すようにするには、実際の楽天RSSのデータをログに取って、それを元にデータを返すように作りこむ必要はあります。でも、楽天RSS部分のテストについて先が開けた気がします。micorosoftさん、本当に有難うございました。DdeServerの作成はまだまだ時間が掛かりそうですが、またアドバイス頂けたらと思います。P.S.Advice間隔(更新通知を発生させる間隔)はサンプルソースでは1秒毎ですね。実際の楽天RSSも1秒なのか、設定により間隔を変えれるのか、マケスピのリアルフィードと連携しているのか。その辺りが一番知りたいところでもあります。それによってはテストが無意味になる可能性もあるので。
Dec 23, 2007
コメント(8)
-
KATSの異常終了により取引なし。
取引なし【保有銘柄】なし【総合損益】時価評価額 86,536円(-413,464円)/500,000円(うちクリック証券への入金額:111,055円)今日はログを見る限り、昨日と全く同じ現象で異常終了していました。昨日より少しログを出すようにしていたので何となく見えてきました。いや、それより今日はマルチスレッド処理の方法をさらに変更する必要がありました。先週末まで動いていた処理は、自動購入や自動売却というそれぞれの処理がマルチスレッドで実行していましたが、その処理内は並列ではなく同期を取って直列的に処理されていました。(1)自動購入を1スレッドで実行(先週まで) 自動購入スレッド →DDEクライアントのインスタンス化 →イベントハンドラに割り付け →更新通知開始 ・・・イベントハンドラは全銘柄×全項目のイベントを直列に処理する ※同一スレッドから呼び出されたイベントハンドラは並列に実行されないので、 銘柄数や監視項目数が増えたらとてもじゃないが実行に堪えないこのお陰で相場が開いて時間が経つにつれて処理が遅延し、最終的には更新通知が止まってしまうような形になり途中から購入してくれなくなっていました。この問題を解決するために、土日で考えたのが「監視銘柄毎に新しいスレッドを立てて並列に処理しよう」という方法でした。しかし月・火と即異常終了するありさま。作りこみの甘さもありますが、この方法には致命的な欠陥がありました。。。(2)監視銘柄毎にスレッドを作成(昨日・今日) 自動購入スレッド →DDEクライアント用のスレッド開始 →DDEクライアントのインスタンス化 →イベントハンドラに割り付け →更新通知開始 ・・・イベントハンドラは全銘柄×全項目のイベントを並列に処理する ※イベントハンドラは複数スレッドが同時に動くが、スレッド数が25までなので それ以上になるとロックされる(監視から外れない限り次の銘柄の監視が出来ない)どちらにしてもこのままだと監視出来る銘柄が20銘柄に満たなくなり、自動売買として全く意味を成さなくなります。どちらにしても作り変える必要が出たのです。そこで今回考えたのが、監視銘柄のインスタンスは同一スレッドで作成するが更新通知を受けた時の処理を並列で行うという方法です。更新処理の1つ1つは非常に短時間で終わるので、いくらスレッドの最大が25個でもどんどん消化されて進みます。(3)更新イベント毎に新しいスレッドを開始 自動購入スレッド →DDEクライアントのインスタンス化 →イベントハンドラに割り付け →更新通知開始 ・・・イベントハンドラは新しいスレッドを開始させ、更新処理を行う ※1銘柄の1項目毎に新しいスレッドを開始する。更新処理は25個しか同時に動かないが、 1つ1つが短時間で終わる処理なので実質並行処理が行われる。 銘柄数・項目数に上限が無いのでプログラムも書きやすい机上の空論なら駄目なので、テスト用プログラムを作成してパフォーマンスを測定してみました。すると、シングルスレッドに比べておよそ6倍の速度で処理を行う事が分かりました。ちなみに2番目の方法は、スレッドが25個に達した時点で実際問題として処理が止まってしまうので結局使えませんでした。現在、この新方式を自動購入に組み込んでテスト中です。テストを終えて、自動売却にも反映させてから日記をアップしようと思いましたがそれだと夜中になると思ったので先に投稿しました。これから開発とテストに集中して、自信を持って明日の相場に臨めたらなぁと淡い夢を抱いています。結果は明日の日記を楽しみにして下さい(笑)。ちなみに明日は飲み会なので詳細報告は夜中です。出来るだけ速報は入れたいと思います。
Dec 18, 2007
コメント(1)
-
原因は「新たなマルチスレッド問題」でした。。。
今日のKATSの異常終了の原因は、この休みにリニューアルしたソースコードがもたらした、また新たな問題でした。大きな変更点は「DDEクライアント毎に新しいスレッドを立てる」事でした。しかし、また私のマルチスレッドに対するスキルの低さを露呈してしまいました。まず銘柄毎に楽天RSSによる開始を行う時、スレッドを起動します。そのスレッド中でDDEクライアントをインスタンス化し、更新通知をスタートさせます。しかし、その通知を停止させる時にDDEクライアントの解放が出来ていませんでした。私の中では「スレッドを停止させたらDDEクライアントも死ぬだろう」と勝手に思っていたので、停止させるつもりでスレッドの解放を行っていました。でもテストしてみると、DDEクライアントのインスタンスは死んでいませんでした。楽天RSSを停止させてみると、それまで起動していたDDEクライアントのゴミが一気に停止されるログが吐き出されました。スレッドを停止させる時、いきなりDisposeするのではなく、ちゃんとスレッドを中断させるメソッドを呼んでDDEクライアントを解放してからDisposeするように変更したらその問題はなくなりました。次の問題はまだ解決していません。何しろ、VB.NETのスレッド数は「プロセッサ数×25」という制限があるからです(汗)。メインスレッド。そして自動購入、自動売却。また楽天RSSの異常や大引け後のシャットダウンを監視しているタイマーイベント。これだけで4つのスレッドを使用しています。仮に持ち越し銘柄が1つも無くても、購入銘柄の監視に21銘柄しか使えないという事が分かりました。かなり致命的です。解決するには監視銘柄ごとにスレッドを立てる事をやめるしかありません。この休みに変更した内容をまた後ろ向きに直す気がしてすごくヘコみます。何か対策を考えないといけません。この制限のせいで、今日は持ち越し銘柄プラス購入監視銘柄。さらに購入監視銘柄と持ち越し銘柄に同じものが入っている事による更新通知をもらえないバグ。それに加えてインスタンスの解放ミスが重なり、バグのオンパレードとなりました。明日は解放の問題と同一銘柄問題は解決されています。スレッド数の上限問題についても、今から監視銘柄抽出を行いますが20銘柄を超えるようであれば20銘柄程度に抑える事によってとりあえずは回避出来るでしょう。あと、他のバグによって異常終了しない事を願いながら・・・・・・と日記を打っていたら、裏でずっと起動していたKATSが異常終了しました。しかも致命的なエラーにより強制終了です。。.原因は今のところ全く不明です(T-T)明日が不安です。
Dec 17, 2007
コメント(0)
-
明日に向けてKATSを最終調整
金曜日から土曜日に掛けて、かなり大掛かりな修正をしましたが、それに伴い修正しないといけないのに忘れている部分がありました。同じ銘柄を1日に複数回購入した時、取得単価を保有銘柄一覧から取得していました。その方法だと、2回目以降の取得単価が狂います。その値は当日の平均取得単価を表しているので純粋に2回目の購入株価と違ってくるのです。その問題を解消するには、約定一覧から約定単価を取得しかありません。元々保有株一覧に市場コードが無いので約定一覧から取得しないといけませんでしたのでそのついでに約定単価を取得するように追加しました。資金が93,000円ほどに増える事もあり、同一銘柄を複数回取引出来るとなれば恐らく取引回数が増えるのでは無いかと思っています。買い注文のロジックを結構変更したので、もしかしたら頻度が減るかも知れませんが。そこで便利機能の一貫として、メールによる売却通知の中に「本日の概算損益合計」を追加しました。先週か先々週ぐらいに売却毎の概算損益については追加していたので、無かった時に比べて便利にはなっていました。でも取引が増えると「結局今日はトータルで勝ってるの？負けてるの？」という時、電卓で各メールの概算損益を合計していました。昼休みにはiアプリから本当の損益を見れますが、次に見れるのは基本的に会社を出た時。それまで我慢できないのでメールに追加した次第です。これで当日の概算損益をメールで把握出来るようになりました。そしてもう1つ。昨日から書いていた購入候補の取得ロジックです。今まではMarketSpeedの「銘柄選択」で自分の購入可能銘柄を抜き出してコピーし、KATSにインポートするという作業を行っていました。金曜日までは資金が少ないせいで対象が300銘柄を切っていました。KATSでのインポート処理に掛かる時間は大体20秒前後ぐらいだったと思います。ですが明日から増資するので対象銘柄数が増えました。MarketSpeedの「銘柄選択」で一度に取得出来るのは300銘柄までです。なので抜き出すには条件を変えて何度かに分けて取得してKATSに追加インポートしなければいけません。明日からの資金だと3回に分ける必要がありました。トータルで掛かる時間は3分程度でしょうか。でも煩わしい手作業が増えて非常にストレスが溜まります。ミスの可能性も出てきます。「それなら」という事で、自動的に全銘柄から購入候補を作成してくれるように方法を変えてしまおうと思いました。全銘柄を取得する方法は結局楽天RSSから行う事にしました。取得時間は10秒強です。取得する項目は銘柄コード、市場コード(市場名からKATSで変換。複数の場合は主市場)、銘柄名称の3つです。・・・但し、その後が長いのです。購入候補への追加判断を行う為に銘柄毎にDDEクライアントをインスタンス化し、終値、前日終値、高値、安値、売買代金等を取得してフィルタリングを行います。インスタンス化してしまえばデータ取得は早いです。オブジェクト指向言語を経験されている方は分かって頂けると思いますが、インスタンス化に掛かるコストは相当なものです。銘柄毎にインスタンス化～開放を繰り返します。4,000銘柄を超える訳ですから嫌でも時間が掛かります。私のPCでは、約10分で抑えるのが限界でした。私のスキルでは恐らくこれ以上速くする事は出来ないでしょう。でも、1ボタンを押せば自動的に処理してくれる事を考えたらミスも少なく便利になったと思っています。ボタンを押して処理している間にメールチェックしたりブログを書いたり、やる事は一杯あるので。という訳で10分で妥協してしまいました(^-^;もし資金が今より遥かに多くなったとしてもそれに比例して時間が長くなる事は無いのでまあ仕方がないと思うようにします。ちなみに明日の購入候補は43銘柄です。フィルタリングにより100分の1になるんですね。ほとんどが購入資金不足で除かれているとは思いますが(汗)。さてKATSも10月末ごろに自動売却のみをリリースした頃に比べたら大きく様変わりしました。あとは成果さえ出てくれたら文句なしなのですが。買い注文の精度アップあるのみだと思っています。頑張ります。
Dec 9, 2007
コメント(0)
-
KATSの大幅改造
今まで課題にしていながら時間が無くて保留していた改善を行いました。それ以外のレベルアップもあり、今回の修正は成績に直結するのでは無いかと思ってかなり期待をしています。１．購入候補抽出来週増資するにあたり必要になった機能です。MarketSpeedの「銘柄選択」で一度に検索出来る銘柄の数は300銘柄までです。それ以上の件数を抜き出そうとしたら複数回に分けて作業を行う必要があります。今までは1度しか想定していなかったので毎回「全削除→取り込み」していました。でもそれじゃあ複数回に分けて取り込めないので追加取り込みする機能も付けました。ただ、仮にもっと資金が増えたら手間が増えるので、MarketSpeedから銘柄選択しなくても自動的に全銘柄から抽出してくれるような何か良い手段が無いか検討する必要もあるな、と思っています。「全銘柄」の銘柄コード、市場コードを取得する何か良い方法はありますか？銘柄の増減があるので手作業で一覧をメンテするのは嫌ですから、機械的に全銘柄を取得する方法があれば助かります。２．同一銘柄の複数回購入今回一番「追加したい」と思っていた機能です。大幅な修正が入りました。今まではある銘柄を購入したら、その銘柄を購入候補から外していました。なので当日何度も売買出来る余力があっても、1度購入したらもうその銘柄を再び購入する事は出来ませんでした。利益のチャンスを逃す要因にもなっていました。今回の修正では、購入候補銘柄毎に「購入余力」という項目を追加する事により、まだその銘柄を買えるのかもう買えないのかを判断させる事が出来るようになりました。また、持ち越し銘柄を差金決済取引で購入してしまい売れなくなるという問題に対しても対応しましたので「持ち越し銘柄は購入監視出来ない」という問題に関しても対応出来ました。例えば4万円の持ち越し銘柄と余力6万円があり、当日その銘柄を売って余力が10万円に戻ったとします。さらに同じ銘柄を10万円分購入するともう6万円分しか売れなくなりますが、そういう事が起こらないように、いくら持ち越し銘柄を売却してもその銘柄の購入余力が6万円だという判断が出来るようになっています。３．購入ロジックの精度アップ色々細かく修正したのでひとことでは解説出来ませんが、とにかく悪い方向には絶対行ってないと思う改良です。急騰だと判断する条件の見直しと、一番大きいのは「VWAP乖離率」の扱いです。今まで電卓で簡単に計算して「この辺りで設定していたら良いのではないか」と適当にロジックに組み込んでいましたが、今回はMarketSpeedの1分足でチャートをVWAPに変更し、どんな値動きの時にどんなVWAP乖離率になっているのか入念に調べました。そして「買い注文を見送る／積極的に買いたい」条件に加えました。ボリンジャーバンドに似た使い方が出来るのでは無いかと思っています。また資金が増える事により、より分散投資が可能になると思います。今までは「半力買い」のロジックで動作させていましたが、資金の3分の1ぐらいの額で買うように修正しています。もちろん最低購入単位が超える場合はその限りではありませんが。それ以外にも細かい部分はもっと沢山修正しています。あと組み込みたい機能としては以下のようなものがあります。・ウップス作戦 HMさんやゴールデンクロスさんから勧められた買いシグナルです。 「私が購入した株の本」の真ん中にある「たった7日で株とチャートの達人になる！」にも 載っています。 「前日安値よりも安く寄り付いた後、前日安値を越えたら買い」という単純なもので ありながら、考案したラリー・ウィリアムズ氏が「最も自信がある」と言っている 作戦です。本人曰く、勝率は70%を超えるとか。 今の自動購入ロジックとは別に並行で起動して効果を確かめてみたいです。・ソースコードを修正しなくても色々設定出来る仕組み 今はトレーリングストップ率、メール送信のON／OFF、本番／テスト環境の 切り替え等を画面で設定出来ます。 でも、例えばログインユーザーIDやパスワード、メールアドレス等の情報は 設定ファイルに外出ししていはいるものの画面からの修正は出来ません。 今後のために、画面で設定出来るようにしておきたいです。まだまだやりたい事は一杯ありますが、平日は売買ロジックのチューニングやバグ修正を最優先に行いますので、休日の時間の許す限り組み込んで行けたらと思います。年末年始の休みにはまとまった時間が取れるかも知れないので、構想を練っておきたいです。一番恐いのは月曜日に異常終了する事です。いくら取引時間外にテストをしても、ザラバ開始直後に発生するバグは過去に何度も経験してます。何とか動いて欲しいです。。。
Dec 8, 2007
コメント(11)
-
明日から気持ち新たにスタートします！
今日フェイスを高値掴みしてしまった理由が分かりました。私のプログラムミスで、高値での買い注文を見合わせるというロジックと、VWAP乖離率が高い株価(VWAPに比べて高すぎる株価)の時に買い注文を見合わせるというロジックの2つについて「○○なので買わない」というログを出力しておきながら実際は買い注文のロジックを抜けずに買ってしまっている事に気付きました。完全なバグです。もちろん今晩修正します。あとKATSのロジックで気になっている点が3つほどあります。１．購入候補の抜き出しロジック条件の中に「ティック差」というものがあります。当日何ティック上下したかを評価し、最低ティック数以上値動きしないと「値動きが悪い銘柄」という事で候補から外すロジックです。現在10ティックにしてます。でも、よく考えたら株価が高い銘柄は10ティック動いただけで値動きが良いと判断するのはおかしいと今になって気づきました(^-^;値動きはパーセンテージで判断した方が良いと思うので修正します。可能なら今日中。無理でも次の休み中には直したいです。２．大引け前に購入して持ち越してしまう購入ロジックに、特に時間帯を意識して買うというロジックはありません。なので、大引け前に平気で購入し、そのまま持ち越すケースも結構あったりします。持ち越すという事はギャップアップの可能性もあればギャップダウンの可能性もある訳です。損すると決まってはいませんが、リスクは高まります。ある時間帯を過ぎたら購入をやめるとか、あるいは大引けまでに売れなかったら強制決済するなど、リスク軽減のロジックを考えないといけないかも知れません。但しこれに関しては即対応しないといけないとは思っていなくて、必要だと思ったらその時に組み込もうかと思います。今は様子見です。３．同一銘柄の複数回売買手動で購入していた時には自動売買にバグがあり、その対応も終わって今では当日に同じ銘柄を複数回購入しても問題なく動作していました。でも今は、自分でも認識している不具合・・・というか納得いかないロジックになっています。実は今、自動購入では「一度購入したら購入候補から消す」ので、二度目以降の購入は無いのです。例えばある銘柄を少ない余力の時にたまたま購入したとします。その後余力が復活して同じ銘柄を充分買える状態になっても、一度買った銘柄は候補に居ないので買わないのです。これはかなりアホなロジックだと思っていました。でも対処法が思い浮かびませんでした。今日おぼろげに思いついたロジックは「銘柄毎の購買余力」を計算して持たせる事です。購入候補全てに「その銘柄に何円まで使えるか」を持たせます。当日開始時の値は全資産(保有株の評価額も含む)です。そして銘柄を買うたびに、購入候補にその銘柄がいたら購入可能額から購入額を引きます。そうすれば残りどれだけ購入出来るか分かります。持ち越し銘柄が購入候補にいれば最初からその額を引いておく事も忘れてはいけませんね。そして、購入可能額がその銘柄の最低購入価格を下回った時に初めて、購入候補から削除すればOKです。文字で書くと簡単ですが、このロジックを組み込むにはデータベースからロジックまで影響範囲は結構広いので、時間に余裕のある時にゆっくりと組み込みたいです。それまでは「持ち越し銘柄は購入候補に入れない」事を運用でカバーし「同じ日に同一銘柄は1回しか取引出来ない」事を我慢するしか無さそうです。色々書きましたが、ナンだかんだ言って現在自動売買が本番稼動されている訳です。私が株を始めたのは2年前の12/7。最初の1ヶ月は右も左も分からないまま、スイングトレードもどきの事をやってました。年が明けて、正式にデイトレをしようと思ってスタートしました。当時のブログタイトルは「朝15分のデイトレーダーKNIGHTの日記」だったと思います。9:00～9:15の間だけ自宅PCでデイトレしてから出勤していたのでそんな名前でした。デイトレを始めてすぐにライブドアショックがありました。自分のトレードに自信が持てなくて「デイトレを辞めようか」と悩んだ時期が何度もありました。色々な人の意見に影響を受けて、しっかりした信念が無かったので本当に「自分にとって何がベストなんだろう」と思っていました。何をやっても駄目なまま、資金を減らす日々が続きました。今年の春だったか、電車のダイヤ改正により15分間のデイトレすらままならなくなり、10分間ほどPCでデイトレをしたらあとは携帯で売買するようになりました。ブログタイトルも現在の「会社員KNIGHTのデイトレ日記」に変えました。「朝10分の～」に変えても、それ以降も携帯で売買してるし、そんな何分という事よりも「会社員だけどデイトレをしている」というのを強調したかったからです。でもデイトレを始めて1年半ぐらい経ち「もう駄目だ」とうい事で、ようやく自動売買を開発する決心をしました。自分のメンタルの弱さとザラバ中の監視能力の無さ(会社員なので監視出来ない)ではデイトレを続けるのは不可能。かと言ってスイングトレードは本望じゃない。じゃあ何が出来るかと考えたら、もう自動売買しか残ってませんでした。自分が作ったルールを守れないメンタルの弱さも自動売買なら問題ありませんし。という事で今年の夏から約5ヶ月。間に休止期間はありましたが、ようやく自動売買の形が出来てきました。10月頃はまだ自動売却しか本番稼動出来なくて、購入は手動で行っていました。「買いタイミングさえ良ければ勝てる」と思い込んでいましたが、売却ロジックも甘くて結果的には損切りを繰り返す事がほとんどというロジックになっていました。でもロジックを見直し、今週から本格的に自動売買を始める事が出来ました。ここまで来て、もう売買はKATSに任せると決意出来ました。これからは結果を見てロジックをチューニングしていく事に注力します。自分で売買しないので、もう9:00過ぎまで自宅に居る必要も無くなりました。という訳で、フレックスで10:00出勤していたのを明日から9:30出勤に変更しました。気持ち新たに、ブログタイトルも一新しようと思います。「会社員KNIGHTの株自動売買」に変更します。この日記に気付いた方で私のブログにリンクを張って頂いている方は、恐れ入りますが変更を宜しくお願いします。m(_ _)m資金が危機的状況に陥り、段階的に何度も資金を投入して今では43万円。来週の月曜日に7万円増資し、区切り良く合計50万円を株につぎ込んで増資を終える予定です。恐らく12/10時点での資金は10万円弱だと思いますが、それを元手に頑張る所存です。今後とも、どうぞ宜しくお願いします。
Dec 4, 2007
コメント(6)
-
思い切って自動購入を作り込みました。
昨日、今日とシミュレーションしていたKATSの自動購入ロジック。とりあえず異常終了する事なく動いていたのと、手動で買うのに比べて特別おかしなタイミングで買うという実感も無いので「ものは試しだ」という事で我慢出来ずに明日本番リリースしてみる事にします。今日は判断ロジックを大幅追加したのでもしかしたら異常終了するかも知れません。その時はKATSを再起動し、自動売却のみをスタートするようにしましたので大丈夫でしょう。購入に踏み切る条件をかなり辛くしたつもりなので、下手したら買ってくれない可能性もあるかも知れません。それは明日帰宅してから確認したいと思います。・・・明日は飲み会なので帰宅は遅くなるし酔ってるので判断出来ないかも知れませんが(^-^;簡単に購入条件を書くと・安値より2%上昇している事・急騰している事・VWAPより高値にいる事・S高付近ではなく、板も空いてない事・その時点の日経225より日経先物の方が高値である事そしてもちろん、購買余力がある事です(笑)。購入株数の計算も、なるべく分散投資出来るような株数を計算。但し購入可能な最小株数がすでに余力の2分の1を超えている場合は仕方が無いので購入。こんな感じです。ロジックはそれほど深く検証も検討もしていない暫定的なものです。しかも多分異常終了すると思います。そうしたらメールも来るので手動で買います。・・・自動売却も一緒にポシャッたら、もう笑うしかないです。明日は大阪ですが出張ですので9:00前に自宅を出ます。ザラバ開始時のKATSの状態を見れないのが非常に不安ですが、メール通知を信じて見守りたいと思います。
Nov 27, 2007
コメント(3)
-
自動購入シミュレーション初日
今日は初めてKATSの自動購入を大引けまで起動させていました。自動売却では多くても同時に2～3銘柄の監視しか行っていませんので、今回26銘柄を監視して自動売却と同時にずっと動かすのは「異常終了しないかな」と非常に心配でした。でもマルチスレッド処理の問題はもう無さそうです。自動購入と自動売却は独立したスレッドなのでお互い干渉する事無く頑張って動いてくれるようです。26の監視銘柄のうち、6銘柄には買いサインが出ませんでした。20銘柄についてそのタイミングに本当に買っていたらどうなるか検証してみました。詳細を書くと非常に面倒なので結果だけ書くと、勝ち10、負け8、引き分け1、購入不可1(買いサインが出た時は自分が買えない額だった)です。勝ち負けの額にもよりますし、先に購入していたら売るまで次の銘柄が買えない可能性があるのであくまでも全てそのタイミングで買ったら、という結果ですが。あと自動売買だと低位株は1ティック当たりの比率が高すぎて安易に狙えないという事も分かりました。購入だけ逆張りでやっている今はまだマシですが、購入も順張りで行うとなると、損切りさせられる可能性が高くなります。超低位株は監視対象から外そうと思います。最低130円以上で。・・・でも適当に作ったロジックでも手動より精度が高いです(汗)。今日の結果を受けて修正したい部分が出てきたので今晩またロジックを改良して明日試したいと思います。どちらにしても手動で買う時は適当なものなので「年末までに」と言わずもっと早く自動購入を本番稼動させようと思います。でもその為にはクリアする問題も一杯あります。まずは単純に成行買い出来ない(余力が無い)のでどう指値を入れるか。指値だから約定しない可能性を考えないといけないのか、等。次に何株買うのか。全力だとリスク分散にならないけど単位株数買えば必然的に全力になる銘柄もあります。その辺り、どういうロジックで購入株数を決めるのか考えないといけません。もう1つ問題は、買いサインが出た銘柄がたまたま余力不足などにより買えない場合、その銘柄をどうするのか。もう監視から外すのか、それとも買えるタイミングになれば狙うのか。一度サインを見過ごして次の買いサインがちゃんと拾えるロジックが思いつきません。まだ検討項目は色々ありそうです。難しいです。ちなみに、今日は間違って購入シミュレーションでもメール送信させてしまいました(^-^;大引けまでに20通ぐらい余分にメールが来てかなりウザかったです(笑)。
Nov 26, 2007
コメント(0)
-
自動購入への準備
一昨日から昨日にかけて嫁さんの実家に行ってましたし、今日は夕方から一人で自分の実家に行ってました。親がパソコンを始めて最初の年末なので年賀状印刷などのサポートです(笑)。そんな事もあり、自動購入については限られた時間で集中して進めました。自動購入ロジックよりも先に、購入候補となる銘柄の絞込み処理を作成しました。現在手動で購入を行っていますが、銘柄の絞込みはExcel/VBAを使っています。まずMarketSpeedの「銘柄選択」で、自分が購入出来る価格帯の銘柄に絞って検索し、CSV(実際にはTAB区切りなのでTSV)形式でコピーします。それを自作の絞込みツール(Excel)に貼り付け、色々な計算式を駆使して計算・順位付けなどを行い、さらにExcelから楽天RSS経由でも当日の高値・安値・売買代金などを取得してそれらも判断材料に入れ、条件に叶わないものは削除して最終的に20銘柄ほどに絞り込みます。それを手動でMarketSpeedのザラバ情報に打ち込み、さらにGMOインターネット証券のWebサイトにログインしてポートフォリオにも手入力します(これにより携帯から情報が見やすくなります)。こんな面倒臭い事をしていますが、KATSにそれらの情報を渡そうとする時、Excelを見てKATSの画面に手入力で叩く・・・なんて事をしたらかなり馬鹿らしいです。という事で、今Excel/VBAでさせている処理を全てKATSで行う事にしました。MarketSpeedの「銘柄選択」からコピーする事は必要ですが、クリップボードにコピーしている状態でKATSを操作し「購入候補Import」を行えば、今まで手作業で10分ほど掛けて行っていた毎晩の定例作業を30秒ほどで行う事が出来るようになりました。作業時間の効率化も嬉しいですが、何より手順の多さにゲンナリしてましたので、操作が簡単になったのが非常に大きいです。これでMarketSpeedやGMO証券への手入力も無くなる！？と言いたいところですが、まだ自動購入が作成していないのでこの作業はしばらく続くでしょう。そしてKATSに登録された購入候補に対して監視し、ここだと思えば購入処理を行う「自動購入」ですが、とりあえず非常に簡単なロジックだけ入れてみました。「まず手始めに」って事で購入(シグナル発生)時にログに残すようにしました。実際購入は行いませんしまだメールも飛ばしません。バグがあったらエラい事になるので。。。KATSは久しぶりに本番リリースされましたのでバージョンが上がりました。安定稼動していたのがこのリリースによってまた不安定になる事だけを非常に恐れています(汗)。朝一番に自動購入シミュレーションと自動売却を起動させ、自動購入のせいで異常終了するような事があれば、すぐに止めて自動売却部分のみ開始して出勤したいと思います。これから徐々にロジックの精度を上げ、せめて今年中に自動購入を実際に動かしたいです。冬の賞与が出たら7万円の増資予定です。全自動売買に向け頑張ります。久しぶりにKATSの画面を紹介です。以前ご紹介した時は自動売買と手動売買を切り替えるような画面構成でしたのでGUI的には見映え重視でした。その後自動売買の追加を試みた時(企画倒れ)にはこんなへんてこな画面になってましたが(苦笑)。今は基本的に自動売買の開始／終了しかいらないのとあとは設定や購入候補／売却候補の閲覧のみだと思っているので必然的にデザインが一新されました。もし「手動売買出来る環境も追加しようかな」と思ったら、メインウィンドウの中に子ウィンドウを銘柄の数だけ開けるようにしたいなぁと考えています。
Nov 25, 2007
コメント(0)
-
強気！？弱気！？
自動売却処理については安定稼動しているKATSですが、現在色々と組み込み中です。まず昨日のDdeManagerの記事に関する事ですが、今までは楽天RSSに対する情報取得は変更通知イベントによる更新のみを行っていました。「銘柄名」や「市場部略称」と言った不変の情報に対しても監視を行い、イベントハンドラ中で更新を行っていました。イベントが発生するのは1度なので無駄ではないと言えば無駄ではないのですが、監視対象に項目数が増えればパフォーマンスにも少なからず影響が出ると思うので無駄な処理はやめようと思ってイベント型ではなく要求型で取得するように変更しました。ついでにDdeManagerのメソッド体系についても見直し、より使いやすくしたつもりです。あと自動購入の枠組みだけ出来ました。枠組みというのはロジックでは無く、ロジックを書くクラスが出来ただけです(苦笑)。でも、一応メイン画面から自動購入の開始が押せますし、押したらバックグラウンドで自動購入スレッドが立ち上がって自動売却とは並列に処理を実行し、中断も画面から行うようにしています。現在は自動購入を開始してもテスト用に作った情報取得の処理が走って終わりなのですが。でもロジックさえ固まればすぐ実装してシミュレーション出来る体制にはなったという事で半歩前進ですｗ今後組み込みたいと考えている処理も検討しています。自動購入はもちろんですが、他に色々な案が浮かんでいます。今自動売却について1つの発想が浮かんでいます。それが「強気／弱気」を盛り込む事です。具体的には、トレーリングストップの率を相場全体の流れによって動的に変更出来ないかという事です。例えばデフォルトを3%としていますが、相場が強いと感じたらそれを3.5%、4%、ぐらいまで上げ、振るい落としに掛かって売られないように強気にいきます。逆に相場が弱いと感じたら率を2.5%、もしくは2%ぐらいまで下げ、売り注文の執行を早める方向に作用させたいです。判断材料としては、日経225や日経先物を元に行いたいなぁ、と。もし今日の相場の場合、前場は損切りする可能性が高いけどその額をなるべく減らすためにTS率を下げ、相場が強くなってきたと判断したらKATSが自動的にTS率を大きくして行くのです。なかなか面白そうな考えだと自画自賛したのですが。。。(笑買い注文の精度も大事ですが「場を読んだ売り注文」もそれなりに思惑を加える事が出来ると思いました。「強気／弱気」モード。どうでしょう？ｗ・・・さて今日は寝る事にします。明日はどんな相場になるんでしょうね。
Nov 20, 2007
コメント(2)
-
VB.NETで楽天RSSから情報を取得する方法
今回はKATSでも使用している「NDde」というクラスライブラリを使って楽天RSS(Realtime Spread Sheet)から情報を取得する方法をご紹介します。楽天RSSはDDE(Dynamic Data Exchange)という昔ながらの技術を使用してデータ交換を行っています。DDEはWindows2.0の頃からある枯れた技術だそうです。.NET FrameworkはDDEをサポートしていないのですが、ネイティブなコードを書けば呼び出せます。でもそれはかなり敷居が高いです。ですが複雑な処理をラップして.NETのクラスとしてDDEを扱う事が出来るクラスライブラリ「NDde」が無償提供で存在しますので積極的に利用するべきだと思います。ダウンロードしたファイルを展開して.NETプロジェクトからNDde.dllを参照指定すれば、すぐに使用する事が出来ます。楽天RSSを使用されている方はご存知ですが、楽天RSSはMarketSpeedを立ち上げてログインしていないと使えない仕組みになっています。恐らく楽天証券の口座を開設していなかったりMarketSpeedの使用料を払っていない人が楽天RSSだけ使用する事に歯止めを掛けるためだと思っています。NDdeは楽天RSSを経由して情報を取得するので、.NETから情報を取得するためには事前に・楽天RSSを立ち上げる・MarketSpeedを立ち上げ、ログインする事が大前提になります。では実際.NETのソースから使用する部分について解説を続けます。ちなみに私はVB2005 Express Editionを使用していますのでVB2005EEベースでソースを書きます。C#やVB.NETの旧バージョンの方は読み替えて下さい。DDEを使いデータを取得する方法は大きく分けて2つあります。1つは「○○のデータを下さい」とリクエストし、データを返してもらう方法。もう1つは「○○のデータに変更があれば通知して下さい」とお願いし、データに変更があるたびにイベントを発生させてもらう方法。前者は自分から要求しない限りデータをもらえないので、例えば現在の株価などを調べるとなるとループを回して定期的に要求し、今の株価が何円なのか取得する必要があります。その方法でも実現可能なのですが、全く値動きしていないかも知れないデータを要求するのは無駄ですし「定期的」のインターバルの長短によって精度とパフォーマンスのトレードオフを考慮しなければならないので大変です。なので前者は銘柄名や市場名、あるいは「前日終値」など不変データを取得する時に使用するのが適切だと思います。逆に後者はリアルタイム情報の取得に適しています。DDEに対し「現在値(株価)の監視を開始して」と命令すると、その銘柄の株価に変更があった時にイベントが発生します。なのでこちらが一定のタイミングで「今何円か」と聞く必要なく、イベントハンドラに「株価が変更された時の処理」を記述するだけでよくなります。これはVBやC#の利点だと思うので是非使いたい機能です。前置きはこのぐらいにして実際のコードを紹介します。NDdeにはNDde.Client.DdeClientというクラスがあり、このクラスを使って情報を取得します。DDEにはサービス名、トピック名というものがありますが、楽天RSSに置き換えて考えるとサービス名は「RSS」、トピック名は「銘柄コード.市場コード(9898.Tなど)」です。DdeClientのコンストラクタにはこの2つを指定しないといけません。つまり、扱う銘柄の数だけDdeClientのインスタンスを生成する事になります。Dim ddeClient As DdeClient = New DdeClient("RSS", "9898.T")のような感じです(こうやって名前空間を省略して記述するには、ソースの先頭に「Imports NDde.Client」が必要です)。では早速、このDDEクライアントで9898.T(サハダイヤモンド)の株価を取得してみましょう。Dim byteData as Byte() = ddeClient.Request("現在値", 1, 6000)これでOKです。第二引数の「1」はお作法だと思ってもらって結構です。「6000」はタイムアウトのミリ秒で、この設定だと1分間までは応答を待つ事になっています。もっとも、この処理に1分掛かってるようじゃ明らかに異常ですが(汗)。ただこのままだと問題があります。返って来るデータがバイト配列です。扱い辛いですよね。データを文字列で返してくれるシグニチャ(メソッドと引数の組み合わせ)もあるのですが、それは使わずバイト配列を返してくれるこのメソッドを使用する事をお勧めします。株価なら良いのですが、銘柄名称などの2バイト文字を取得する時、文字列で取得すると気持ち良く文字化けしてくれます(笑)。何故なら楽天RSSは文字コードをShift-JISで返すようなので、.NETのUnicodeとは文字コードが異なるからです。化けてしまったデータはもうどうしようもないので、バイト配列でもらって自分でエンコードしてやる必要があるんです。具体的にはEncoding.Default.GetString(byteData, 0, byteData.Length - 1)と書けます(こうやって名前空間を省略して記述するには、ソースの先頭に「Imports System.Text」が必要です)。また、楽天RSSから取得される数値データには余計な文字を含むものが多いです。例えば株価を取得しているのに「150.00」など。文字列で取得してこんなのが返って来ても不便です。見栄えよくするため、CInt(price)で整数型に変換してやると良いでしょう。ただ現在値など、ザラ場開始前に取得すると空文字("")を返してくるものは要注意です。0円ではなく、まだ値がない状態です。その時にはCIntで変換を掛けると異常終了しますので考慮が必要です。続いて、2つ目の方法(変更を通知してもらう方法)を試してみましょう。変更を通知してもらうメソッドはDdeClientのStartAdviseメソッドです。Subなので戻り値はありません。ddeClient.StartAdvise("現在値", 1, 6000)と記述します。こうする事によって、DDEクライアントの「現在値(株価)」に変更があった時にclientの「Adviseイベント」が発生します。そのイベントはVBで拾わないといけません。でも定期的に「イベントが発生したかな？」などと調査するのではなく「イベントハンドラを追加する」という作業を行います。AddHandler ddeClient.Advise, AddressOf Client_Adviseと記述したとします。すると、ddeClientインスタンスでAdviseイベントが発生すると、Client_Adviseというメソッドが起動されるようになります(メソッド名の「Client_Advise」は任意)。この記述を書かないと発生したイベントは拾えないので、注意が必要です。私もハマッたのですが、ddeClient.StartAdvise("現在値", 1, 6000)AddHandler ddeClient.Advise, AddressOf Client_Adviseという2行を書いてやると、1行目を処理してから2行目を処理するまでの間に発生したイベントは拾えません！つまり開始した直後のイベントが無視される可能性があるのです。なので、イベントハンドラの登録が先だという事に注意して下さい。AddHandler ddeClient.Advise, AddressOf Client_AdviseddeClient.StartAdvise("現在値", 1, 6000)ちなみに、他の項目の監視を開始して変更が発生した時でもイベントは「Advise」1つだけだという事に注目です。つまり複数項目を監視させている場合にはイベントハンドラ中で「どの項目に変更があったのか」を判断する必要があるのです。では、AddHandler ddeClient.Advise, AddressOf Client_Adviseclient.StartAdvise("現在値", 1, 6000)client.StartAdvise("高値", 1, 6000)client.StartAdvise("安値", 1, 6000)と書いた時に、どうやって変更通知を処理するかについて説明します。イベントハンドラメソッドは、名前は何でも良いのですが引数の型や数はイベントの規則に従っている必要があります。NDdeClient.Adviseイベントの引数はNDde.Client.DdeAdviseEventArgsですが、これは従うしか無いのでお作法だと思ってこう記述します。Private Sub Client_Advise(ByVal sender As Object, ByVal e As DdeAdviseEventArgs) ： ：End Subこの引数が非常に重要です。senderの実体はDdeClientクラスのインスタンスです。DdeClientにキャストしてやれば、Topicプロパティの値を見る事によって「どの銘柄に変更があったのか」を知る事が出来ます。Dim client as DdeClient = DirectCast(sender, DdeClient)Dim topic as String = client.Topic監視する銘柄が複数で、それらに全く同じイベントハンドラを割り当てる場合は無くてはならないものです。次に、監視銘柄のどの項目に変更があったか知る必要があります。それはもう1つの引数であるeを使います。「e.Item」が項目名ですので、例えばIf e.Item.Equals("現在値") Then '現在値に変更があった時の処理Else ：という判断が可能になります。また変更されたデータそのものは「e.Data」で、バイト配列です。DdeClient.Request()メソッドで返って来るバイト配列と同じように扱います。長くなりましたが、以上がNDdeというクラスライブラリを使ってVB.NETから楽天RSS経由で株式情報を取得する方法です。エラーハンドリングやその他必要な情報を省略して本当に基本的な部分しか書いてませんが参考になる方にはなるのでは、と思います。私はもちろんこれらをベタで書いている訳ではなく、使いやすい部品としてDdeManagerというユーティリティクラスを作成しています。もし「欲しい！」という方がいらっしゃれば連絡下さい。いかなる不具合が発生しても保証しないという条件付きで、無償で提供します(笑)。「いや、今後の開発の為に是非寄付させて欲しい」という奇特な方がいらっしゃれば遠慮なくお申し出下さい。それも大歓迎ですよｗ
Nov 19, 2007
コメント(12)
-
もう異常終了しないぞ！！！
昨晩は修正後も「本当にこれで大丈夫かなぁ。。。」と不安でしたが、今晩は自信があります。異常終了した原因も分かりました。やはりマルチスレッド処理でテーブルを更新するある処理が排他制御により更新不可になりハンドルが無くなり、同時に非同期で動いている別の更新処理でNullReferenseExceptionが発生してアプリが落ちている事が判明しました。その対処もうまく行い、明日はちゃんと動いてくれると確信しています！マルチスレッド処理を根本から見直しました。簡単に言えば、同一テーブルの更新を複数のスレッドから非同期に行うのではなくあるスレッドが非同期更新の内容を反映させる形で一手に引き受けて一箇所で更新するようにしました。処理の衝突も不整合も全く起こらないようになりました。明日はKATSの異常終了にビクビクする事無く売買に集中出来そうです(^-^)・・・って言うか飲み会から帰ってこの時間まで調査～修正～テストって。「ほんま好きやなぁ」と思います。。。(^-^;
Nov 14, 2007
コメント(0)
-
これでバグが直ったのかな。。。(不安
UnhandledExceptionイベントがメインスレッドでの例外しかハンドル出来ない事を今日知りました。まだまだ勉強が足りません。まずはBackgroundWorkerの完了処理で、自動売却スレッドでハンドルされなかった例外を処理するように追加ロジックを入れました。自動売却を再び起動するようにしました。でもこれは傷口に絆創膏を貼っただけです。傷を治した訳ではありません。早速マルチスレッド制御関連を見直しました。詳しくは書きませんが、同期処理や細かい制御等を色々イジってテスト環境上は暫く流しても異常終了しないようになりました。最初は売却候補への追加や削除と楽天RSSからの更新イベントの競合でエラい事になってました。。。ついでに見つかったバグとして、稀に「DDE監視を開始した直後の更新イベントが拾えていない」事に気付きました。DDEクライアントを制御するクラスとしてDdeManagerというのを作っているのですが、そのStartメソッドの中で、DDEクライアントのインスタンス化と監視開始をしてしまっていました。そして呼び出し側は戻り値のDDEクライアントに対してイベントハンドラの追加を行うので、「監視開始」と「イベントハンドラの追加」の間のほんの僅かな時間(恐らくミリ秒単位)で発生した更新イベントを拾う事が出来ていなかったのです。そこでメソッドを2分化しました。「GetClient(インスタンス取得)」→「イベントハンドラの追加」→「Start(監視開始)」というステップで呼び出すようにし、イベントを確実に拾えるようにしました。明日絶対異常終了しないかと言われたら非常に不安です。。。でもリカバリー処理も組み込んだので、少しだけ気は楽です。あとはサハダイヤの値動きに期待するしか無いです。
Nov 13, 2007
コメント(2)
-
「自動購入」に向けて
ようやく自動売却ロジックが落ち着いてきたKATS。おっと、最近書いてないのでご存知無い方もいらっしゃると思うので改めて解説を。KATSは「KNIGHT's Auto Trade System」の略で、私が開発している株の自動売買プログラムに付けた愛称です。「カッツ」と読みます。「勝つ」という意味を込めたり、卓球でカットマンをしている事にも掛かっていてお気に入りの名前です。ちなみにこれがアイコンですｗそのKATS。まだ私が手作業で購入した銘柄を自動的に売却する「自動売却」のみをリリースしていて自動的に購入してくれる自動購入はまだ開発を始めていません。自動売却に関しては本当に単純にトレーリングストップを採用しています。購入時の株価を元に、購入後最高値から○%下がったら成行き売りを敢行します。トレーリングストップは株価が上昇する時には売値(ストップ値)を切り上げ、下降する時には決して切り下げないというルールなので、ロスを限定し利益は無限に追求するという、私が思う理想の売り注文です。但し力の無い相場の時には損切りを繰り返してしまうという特徴もあったり大きな振るい落としには引っ掛かってしまうなど、なかなか難しいところもあります。上昇相場で素直に順張りで攻めるとかなりの好成績を残せると思っているのですが。そんなKATSに自動購入のロジックを追加したいと考えています。いくら自動売却で損切りを自動的に行ってくれるとしても、買いポイントが悪ければ全部損切りにならないとも限りません。購入後も株価が上昇してくれるタイミング・銘柄を狙って然るべき時のみ購入してくれるようになれば勝率も上がるでしょう。自分で購入していると「今日は相場全体の値動きがイマイチだからやめとこう」なんて思考がなかなか出てこなくて、買いたい病で無理やり買ってしまいます。こんな事をしていると最近の下げ相場では全く勝てません。今度どんどん資金を減らしていく事の無いように、買い注文にもちゃんとシステムルールを導入して自動的に行わせるべきだと思っています。現在、何となくイメージしている自動購入ロジックの構成要素はこんなものがあります。(1)トレーリングストップと逆の発想トレーリングストップを全く逆さまに適用したら買い注文で使えるのでは無いかという発想です。具体的には「今日の最安値から○％上昇したら買い」です。高値掴みになる可能性を払拭出来ませんが、順張りで狙うならこれも考えて良い考えかなぁと思います。「この辺りまで下がって反発するかな」と勝手に予想して逆張りで買い注文を入れておいたら購入後も下げて結局損切り、みたいなパターンも多いので、それなら反発を確認してから買えると思うので。寄り付き後に上昇する銘柄も上昇を確認して買えます。個人的には3%はちょっと大き過ぎるかなぁという気がしていて、2%とかで試してみたいです。また、S高付近で寄り付く可能性などがあるのでその辺りも縛りに入れないと恐いですね。(2)日経先物と日経平均を比較する日経先物は日経平均の未来予想図と言えるんじゃないかと思います。という事は「日経平均＜日経先物」の状態だと、今後日経平均は上昇に向かうと見れるんじゃ無いかなと思ったのですがどうでしょう？逆のパターンだと「リスクが高いので買い注文を控える」みたいな事が出来ないかなぁと。東証銘柄のみに適用するのかその他新興市場にも適用するのか等についても検討が必要かと思いますが、面白い判断材料だと思っています。(3)各指数を参考にする東証一部なら日経平均。マザーズならマザーズ指数。JASDAQならJASDAQ指数、と素直にその指標を参考にして購入スタートを決めるという考え方です。ただ具体的にどうなったら買うというロジックがあまり思いついていません。まだ詳しく確認していませんが、楽天RSSで取れる各指標の内容ってそれほど多くないのでは無いかと思います。例えば4本値と現在値、前日終値、ぐらいなのかなぁ、と。それらを参考にして何かシグナルが出せるのか考えないといけません。(4)VWAP(出来高加重平均株価)を参考にするVWAPはデイトレーダーが重要視している指標の1つだと思います。どう参考にするかでロジックはかなり変わってくると思います。当日のその銘柄の約定株価を出来高によって重み付けして平均したもので、現在値がVWAPより高いか安いかによって「今日1日で判断して今の株価が安いのか高いのか」を判断する材料になると思います。「それなら株価がVWAPを下回っている時に買うべきなのか」と言えばそうかも知れませんし、逆にかなりヤバい可能性もあります。角度を変えて見ると、今の株価がVWAPより高いと「今日は現時点で負けている人より勝っている人の方が多い」と言えるので、VWAPより株価が高い時に買う方が安全なのかも知れません。ただ株価がどんどん上昇してVWAPがまだ追いついていない状態の時は購入したら高値掴みになる可能性が高いので、単純に「VWAPより高い」では無く、乖離率をちゃんと見ないと大変な事になると思っています。何にせよ、VWAPはデイトレダーにとって無意味な情報では無いと思うので活用したいです。あとは、当日ちゃんと出来高を伴っているか(板がスカスカだったら恐いので)とか他に判断材料が無いと駄目な場面で購入してしまわないか等、色々シミュレーションしてみたいと思います。これらの構成要素はどれかを採用するか、あるいは組み合わせて判断するかも知れません。買い注文は売り注文時に比べてシミュレーションしやすいと思っています。ロジックを組み込んで「ここで買い！」という時にログ出力だけさせておいたら後から見直してそれが妥当かどうかチェック出来ます。売りならどこで買ったかによって結果が変わるのでシミュレーションが難しいと思います。また、実際購入する時に普通に成行買いで良いのか。また資金に対してどれぐらい突っ込んで買うのかについても検討しないといけません。以前はマルチスレッド処理をするスキルが無かったので「全力買い」を想定してロジックを考えていましたが、せっかく自動売却が複数銘柄に対応出来るので買い注文もリスク分散して行わないともったいないかなぁと思っています。単位株数で全力買いになってしまう銘柄は仕方が無いのかも知れませんが。。。これらの判断材料やその他について、ご意見下さる方は宜しくお願いします！！では今週も頑張って行きましょう。無理しないようにしたいですね。
Nov 11, 2007
コメント(0)
-
何とかリリース出来そうです。
KATSの修正ですが、ようやく月曜日にリリース出来る状態に持って来れました。苦しんでいたのはマルチスレッド処理の改善で、改めて奥深さを感じました。とにかく不整合を起こさないようにするには、干渉しそうな全ての処理を同期化すれば良いです。絶対複数のスレッドが並列で処理を行わないように完全にシングルスレッドで行わせるのです。でもこんな事をすればパフォーマンスがとてつもなく悪くなります。なのでパフォーマンスと安全性のバランスを取らないといけません。同期化する部分を最小限にするためにはどうしたら良いか試行錯誤し、何度も修正してテストしてやっと異常終了せずにバグを修正版が動くようになりました。今回の修正で、以前「ごくまれに起こるけど仕方の無いエラー」だと決め込んでいたSystem.Net.WebException: 基になる接続が閉じられました: 維持される必要があった接続が、サーバーによって切断されましたというエラーが一切出なくなりました。。。GMO証券のWebサービスのレスポンスの問題だと勝手に思っていたこのエラー。恐らく私のマルチスレッド処理の甘さによる、極めて低い確率だけどタイミングが悪いと起こってしまうバグだったんじゃないかと思います。マルチスレッド処理ってテストやデバッグが本当に難しいので再現させたり検証したりは出来てませんが、恐らくそうじゃないかと思います。これで、私が当初考えていた自動売却のロジックは一応完了で、あとはバグフィックスだけになるかと思います。いよいよ自動購入に向けて考えて行きたいです。・・・自動購入ロジックが完成したら、それと自動売却の処理がまたマルチスレッドで干渉してバグを出さないようにしっかり考えたいです(汗)。明日は卓球の試合ですが遠い(大阪市東住吉区)ので6:00起きです。そろそろ寝ます。
Nov 10, 2007
コメント(2)
-
KATSのソースコードを大幅修正
水曜日に発覚した「同日に同一銘柄を複数回買った時に監視してくれない」バグの修正をはじめとした各問題に対応するため、ソースコードを大幅に修正しました。上記問題は、監視銘柄が売却され実際のDBからは監視銘柄が削除されているのにメモリー空間に保持しているDataTableにはまだレコードが残っていて、あたかも「まだ監視している」状態に見えたから次に同じ銘柄を購入しても既に監視中だとみなされて新しく監視を始めてくれないというのが原因でした。これは私のVB2005に対するスキルが低いから起こったバグで、恥ずかしい事です。この問題を解決する為に、定期的にDataTableを作り直す(TableAdapterからFillする)と良いだろうと思って組み込みました。でもテストをするとガンガン落ちまくり(滝汗)。しかも「ユーザーがハンドル出来ない例外」になり、いわゆるWindowsアプリが「ご迷惑をお掛けいたします」などとダイアログを出して突然落ちる状態なので何もログが残らず最悪な状態です。。。今までこんな事が無かったので焦ったのですが、どうやら監視銘柄のDataTableに対して非同期処理が追加したり変更したりしてる中で別の処理がDataTableをクリアしたり読み直したりする事によって起こる「マルチスレッドのハンドリングミス」によるものみたいです。私はJavaでもマルチスレッド処理は苦手な分野なので焦りました。。。とりあえず割り込まれたら整合性がおかしくなる所を「SyncLockブロック」で囲み同期化させました。Javaでいうところのsynchronizedブロックです。これにより異常終了する頻度は大幅に減ったのですが、でもまだ落ちます。「マズい。。。」と落胆しましたが、もしかしたらDataTableのクリアやFillを行わなくてもDataTableのAcceptChangeメソッドによって綺麗にしてくれるか、あるいは削除されたレコードにはちゃんとRowStateに削除された印が付いているので読み飛ばせば良いのでは無いかと思いました。但しこれについては現在マケスピにログイン出来ない状態なので今晩試そうと思います。自分のVB2005スキルの低さを改めて感じました。。。それ以外に「分かっていたけど運用でカバーしていた」不具合・・・と言うか未実装のロジックがありました。まずは「同一銘柄の買い増し対応」。既に売り注文のための監視を行っている銘柄を買い増した時、株数が合わなくなって理想的な動きをしてくれないと予想してました。例えば10株購入してその監視を行っている時、さらに5株買い増した場合。トレーリングストップにより10株が売れてから5株の監視を始めていたと思います。しかも5株を購入後の値動きは繁栄されず、10株が売れた時点からのトレーリングストップで売られます。それではいけないと思い、買いましたら監視銘柄の株数も増やすようにロジックを加えました。これで今まで敢えて避けていた同一銘柄の買い増し」が出来るようになりました。次に「差金取引の問題」。持ち越した銘柄を当日売って、売った資金でその銘柄を買い戻した場合、当日中は売る事が出来ません。でも今のKATSなら必死で売り注文を出して私の携帯にむやみにメールを送りつけるでしょう。売れないのに(苦笑)。それが予想出来たので運用でカバーしていました。でも今回、保有銘柄一覧を取得した時にその銘柄に「注文可能か」を表す区分があってそれを判断して注文不可の保有銘柄なら監視しないというロジックを追加しました。本来売る事が出来ない差金取引をする事自体が問題かも知れませんが、もしそうなってもKATSがおかしな動作をしないようにしました。あと修正したのは、・DDE関連クラスのメソッドの同期化・設定に関する一式を外部ファイルに移動・メッセージ文言などをリソースファイルに移動・メソッドを然るべきクラスへ移動(リファクタリング)・信頼された証明書の登録などです。思いっきり手を入れました。メンテ性向上、一元管理などを理由にしたものが多いです。今後KATSのソースコードを他の方に見せる機会も多くなると思っているので少しでも汎用化させて私のローカル設定を外出しするようにしています。かなり大掛かりに修正したので今晩は念入りにテストしないと来週が恐いです。明日は卓球の試合ですが、明日の晩までもつれこんだら厄介なので今晩完成させないと。
Nov 10, 2007
コメント(0)
-
丸一日掛かりで出張対応＆障害対策を組み込み。
いやぁ・・・今回はマジで疲れました。昨日も2:00頃までブログ書いたりコーディングしたりしてましたが、今朝は早く目が覚めて朝から開発してました。まず最初に、火曜日の晩に東京に移動して水・木と帰宅出来ないのでその間の自動売買を実現する為に自動起動を組み込みました。ぶっちゃけ、嫁さんに・PCの電源ON・マケスピの起動・楽天RSSの起動・マケスピにログイン・KATSの起動・KATSにログイン・KATSの自動売却開始を全てやってもらえたらそんなものは組み込まなくて良いのですが、あまりにも手順が多すぎる上にミスッた時に責めるのも可哀想なので「自動でやるか。。」という事になりました。「VB.NETのClickOnceアプリはコマンドライン引数を渡せない」という事を今朝知ってKATSに自動ログインと自動売却開始のロジックを組み込む時の判断材料をどうしようか悩みました。普段手動で起動した時に勝手に動かれたら面倒なので。アプリケーション構成ファイル(XMLファイル)にON/OFFの設定を書こうかと思いましたがClickOnceアプリはインストール先が裏でころころ変わるし適当ではないと思い、自分が指定した場所にあるファイルを見て判断する事にしました。今はデスクトップに「KATS開始設定」というファイルの中に「FullAutoMode=true」という文字列を見つけたらKATS起動時に自動スタートさせる事にしました。KATS起動時の自動スタート中に、マケスピと楽天RSSの開始とマケスピのログインを先に行うようにしました。これはUWSCによってMarket Speed Shortcut(mss)を操作して実現します。先にマケスピや楽天RSSが起動されていても再起動するようにしています。これで、嫁さんに頼む作業は・PCの電源ON・KATSの起動だけで済むようになりました(^-^)本来ならKATSの起動もスタートアップ時に行えば良いのですが、そこはまだテストがちゃんと出来てないので諦めて、確実にこの2ステップで行きたいと思います。ここまでで夕方まで掛かりました(^-^;その間、二度の食事の時間ぐらいしか休んでません。同時にsippofactoryさんの部屋でチャットは楽しませて頂いていましたが(笑)。次に、ネットワーク障害時に自動リカバリーする方法を組み込みました。これが、何と1:00前まで掛かってしまったんです。。。(滝汗途中に晩御飯とTV、仮眠(疲れたので横になったら2時間ほど寝てしまった)がありましたが。やる事は分かっていたつもりでしたが、非同期プロセスである自動売却処理について画面の停止ボタンではちゃんと動作するのに、タイマーイベント中にネットワークの切断を察知して同じメソッドを起動しても、ちゃんと動作しないんです。動作しないと言っても中断はされるのですが、何故かBackGroundWorkerが終了したというイベントを拾えずに無限ループしたり、無視すると再起動後に自動売却をリスタートさせるとBusyで異常終了したり。この現象を解決するのにマジで5時間ぐらい掛かったと思います。ほんと疲れました。。。という訳でものすごく苦労した訳ですが、ようやく形になりました。これで思わぬトラブル時も稼働率が上がったかも知れません。再起動する事態になった時と見事再起動に成功した時には携帯にメールをくれるようにもしたので安心です(笑)。今日は家族サービスを全然出来なかったので明日は家族とゆっくり過ごそうと思います(^-^;
Nov 3, 2007
コメント(2)
-
自動売買仲間を増やしたいっ
最近ネットやリアルの両方でKATSについて質問される事が多いです。私のプログラムに興味を持って頂く事は非常に光栄ですので、是非皆さんとコミュニケーション出来たらと思っています。そこで、今回はKATSについてちょっとまとめてみようと思います。(1)作ろうと思った理由・会社員なのでトレード時間が限られているから、勝手に売買してくれるプログラムが あれば便利だから・幸い職業柄プログラミングについては初心者じゃないから・メンタル面が弱いので機械的な売買が出来ず、損失をどんどん増やしていて打破したいから(2)開発環境PC：NEC VALUE STARCPU：AMD Athlon 900MHz(恥)Memory：1GBOS：Windows XP Home EditionIDE：Microsoft Visual Basic 2005 Express Edition(3)使用しているツール等MarketSpeed(楽天証券)：銘柄のリアルタイム情報取得用RealtimeSpreadSheet(楽天証券)：銘柄のリアルタイム情報取得用Market Speed Shortcut(mss)：MarketSpeed／RealtimeSpreadSheetの起動／終了・ログイン用UWSC Free版：Market Speed Shortcutの操作用NDde：.NET FrameworkからのDDE通信を実現するクラスライブラリlog4net：Javaで超有名なlog4jの.NET版。ログ出力に使用Microsoft Access：売却候補銘柄の保持に使用(持ち越す可能性があるから)。購入後高値も保持KATS本体：VB2005(.NET Framework 2.0)で作成(4)使用している証券会社GMOインターネット証券：KATSからの余力情報取得、保有株一覧取得、約定一覧取得、注文発注楽天証券：銘柄のリアルタイム情報取得のため(5)最新バージョンの機能・保有銘柄監視～自動売却 保有銘柄をリアルタイム監視し、株を購入して保有銘柄に追加されたら売却の為の監視を開始。 リアルタイム株価を取得して高値を更新したらトレーリングストップ値(逆指値)を切り上げ。 株価が下落してトレーリングストップ値に達したら成行売り。 売却する事を携帯メールで知らせる。・自動終了 大引けを過ぎたら自動終了～PCの自動シャットダウンを行う。・ログ出力 後からトレース出来るように監視銘柄追加／削除、高値更新、売却、異常終了時等にログを出力・オマケ 本番環境／テスト環境の切り替え その他ちょろちょろまずはこんなところで(笑)。
Nov 2, 2007
コメント(2)
-
KATSのログを見て推測出来る事
GMOインターネット証券に出すリクエストがたまに失敗する時があります。今回も、ログの中に5回ほどそういう機会がありました。先日紹介したものです。でもそれはハンドリングし、リトライする事にしましたので問題ありません。System.Net.WebException: 基になる接続が閉じられました: 維持される必要があった接続が、サーバーによって切断されましたそのエラーとまた違うエラーが起きていました。それは12:54～12:55ぐらいの1分ちょっとの間です。GMOインターネット証券に対するリクエストがタイムアウトを起こしていました。まずこれです。System.Net.WebException: 操作はタイムアウトになりました。そしてその後、1分ちょっとの間、System.Net.WebException: リモート サーバーに接続できません。---> System.Net.Sockets.SocketException:到達できないネットワークでソケット操作を実行しようとしました。が出ています。これはすなわち、ネットワークが切断されていた事を意味します。嫁さんに聞くと「全く触ってないし近づいても無い」と言うので、恐らくこれはフレッツ光の調子によってしばらくの間ネットワークが途絶えていたのでは無いかと推測しました。でも復旧後はまたちゃんとリクエストを受け付けてくれていました。幸いにセッションがタイムアウトするような長時間じゃ無かったので良かったです。でも深刻な問題はこっち側ではありませんでした。その時楽天証券もネットワーク切断の影響を受けています。そして、恐らくこの時にMarket Speedがログアウトされてしまっているようです。もちろんRealtime Spread Sheetも一緒です。こちらについては今の所、再ログインするようにオペレーションするような仕組みは用意出来ていません。。。この時刻以降に購入しているモスインが楽天RSSの更新を全く受けていないのを見ると多分間違いないと思います。原因は「ネットワーク切断によるマケスピのログアウト」です。楽天RSSから更新イベントをもらうDDEクライアントのクラスは、通信が切断されたらイベントを受け取る事も可能です。でも私は「受け取ったらからどうする訳でもない」という理由で、特に何も処理をしていませんでした。このような事態も想定して、通信切断時に再ログインというリカバリー処理を検討しないといけないと思います。ただ今すぐに入れれる訳じゃないので土日で何とか組み込みたいです。そして今回切断時間が短かったのでGMO証券の方は再ログインは不要でしたが、こちらも再ログインの仕組みが必要かも知れません。優先度は楽天より低いですが。自動売買と簡単に言っても、色々と想定しないといけない事があります。大変ですね。
Nov 1, 2007
コメント(1)
-
KATSを家族に起動してもらうために。
今日のKATSの例外については、もう異常終了しないように修正したつもりです。それとはまた違う話題なのですが、私は来週の火曜日の夕方から東京に移動し、水・木と東京出張があります。火曜日は自分でKATSを起動して自宅を出ますので全く問題ありません。問題は水曜日と木曜日です。KATSは自動で起動されたりはしないのです。。。「それなら水曜日と木曜日はトレードを休めば良いじゃないか。」と思われるかも知れません。普通に考えたらそうです。でも、もし火曜日に買った銘柄が売れずに持ち越していた場合はどうでしょうか？KATS無しで機械的な売り注文が出せるとは到底思えないので、起動されているのがベストなんです。そこで一番簡単な解決法は、家族に起動してもらう案です。でも、今は私のアカウントでWinXPにログインしてますのでもちろんパスワードが掛かっています。パスワード不要の臨時アカウントを作る事でそれは解消出来ると思いますが、次の問題はMarket SpeedとRealtime Spread Sheetを起動し、さらにマケスピにログイン。さらにはKATSを起動してログイン、自動売却開始、と一連の作業を行わないといけません。マケスピのパスワードを教えるのも抵抗がありますしこれらの作業を覚えてもらうのも一苦労です。間違えられても怒りをどこにぶつけたら良いか分からなくなります。という事で、自動売却を開始するまでのステップをなるべく簡素化し、家族にお願いするしか無いと思っています。(1)PCの電源を入れる(2)専用のアカウントを選択する(パスワード不要)(3)スタートアップで勝手に自動売却開始まで行うように作りこむ。あるいは最低、 それを動かすショートカットのダブルクリック1度だけの手順で可能にするぐらいです。その為の方法を模索中です。KATSを立ち上げたら自動売却のスタートまで自動で行うようにするには自分で作り込めば良いので可能だと思います。マケスピとRSSの起動は、フリーソフトで
Oct 30, 2007
コメント(2)
-
KATSのレベルアップを行いました。
今週から実践投入したKATS。初日には実際株を購入してその銘柄が保有銘柄に追加されて初めて発覚したトラブルもあって暫定的に修正した部分もあり、完成度はまだまだでした。今日はその不具合修正とレベルアップを行いました。(1)市場区分取得ロジックの追加最優先で手を付けないといけない部分です。GMOインターネット証券の保有銘柄一覧取得にその銘柄の市場区分(東証、大証、JASDAQ、ヘラクレス)が含まれていない事を知らず、楽天RSSでのリアルタイム監視をミスってしまいました。すぐに組み込めないし仮に頑張って組み込んでもまた不具合を出してはいけないと思い、暫定的に「全て東証として扱う」という応急処置を行いました。そのせいで木曜日と金曜日は東証(一部、二部、マザーズ)の銘柄しか扱う事が出来ませんでした。今回、保有銘柄の市場区分を取得するために約定一覧を利用しました。約定一覧には市場区分を持っているので、購入して保有銘柄に追加され監視をスタートさせる時に約定一覧を検索して市場区分を付加するようにしました。これで、来週から他の市場の銘柄も扱えるようになりました(^-^;まあ、日本インターが売れてからの話になるんですが。。。(2)不要リソースの開放今までは監視していた銘柄が売れて監視の必要が無くなった時にはリアルタイム監視のプロセスを終了して開放していたんですが、例えば監視中にプログラムを停止した時には監視中のプロセスが開放されずに残っていました。異常終了した時もしかりです。これではリソースを無駄に食う事になりますし、楽天RSSのパフォーマンスが悪くなります。そこでリソースの開放を確実に行うように作りこみました。また自動売却の非同期スレッドはFormを使って行っていましたがバッチ処理なので画面は不要です。これも無駄ですし、自動売却をKATSのメニューから開始・停止を行う時一瞬無意味な画面がチラつきます。なので今回普通のクラスとして実装し直し、綺麗にしました。(3)その他GUIのレベルアップ本来の機能とは関係なく使い勝手等の部分です。例えばメニューに「自動売却開始」があってクリックし、また同じボタンをクリックするとバックグラウンド処理がビジーという事で異常終了していました。なので開始した時には「自動売却開始」を消し「自動売却停止」を表示するなどして誤操作を行わないようにしました。また停止させずにログアウトしても裏で停止したりメニューも不整合を起こさないようにしたり、突然アプリケーションを閉じるなど想定しない操作を行ってもちゃんと後始末を行うように細部に渡りロジックを組み込みました。他にもちょこちょこあるのですが細かいのでここまで(笑)。来週ちゃんと動いてくれるのを期待したいです。バグを出さないように最終チェックを行わないと。。。あと余談ですが、トレーリングストップ率(購入後最高値から何%下がったら売るか)について何%が妥当かどうか悩んでいます。先日宣言した通り、コロコロ変えるつもりは無いので暫くは今設定している3%を採用しますが。単純に考えると、買い値から3%上昇すれば、手数料を無視すれば損しません。逆に利益を出すには少なくとも購入後3%以上は株価が上がらないといけません。また最高値では絶対に売れません。最高値から3%下がらないと売れないんです。こう書くとすごくもったいなく、トレーリングストップってなかなか利益が上がらない手法に思えます。でも違う見方をすれば、明るい評価が可能です。損切りは買い値より3%下までに制限されます。最低でも-3%で免れます。また、最高値から3%下げないうちは株価が上昇しても全く売り注文を出さないので、損はすぐに見限るけど上昇に対しては利益を限定しないというやり方なので「負ける時は限定的でも勝つ時はその利幅を制限しない」という理想の売却方法だと言えるのです。もし「ふ～ん」と思われた方は是非「トレーリングストップ」でググってみて下さい。ちなみにこの率を低くすると売却する可能性が高くなります。なので損切りが小さくなるけど振るい落としに掛かる可能性も高くなるので損切りの回数が増えたりまだ上昇するかも知れないのに押し目で利益確定してしまったり。大きくすると、損切りが大きくなってしまう可能性が高まりますが利幅が大きくなる可能性も。但し保有する時間が長くなってしまうという懸念もあります。この辺りは「正解」が無いと思うので少し期間を掛けて考えるしかなさそうです。「神と悪魔の投資論」では10%がかなりパフォーマンスの出たパーセンテージだと書いてました。でも私はそれは採用しないと思います。。。スイングトレードには適しているかも。
Oct 27, 2007
コメント(0)
-
KATSの実運用開始初日トラブルの原因
KATSというのは「KNIGHT's Auto Trade System」の略で、私が作った自動売買プログラムの名称です。まだ自動売却しか出来ませんが。。。今日、初めて実際にGMOインターネット証券にお金を入金して実運用を行いましたが正しく動作してくれませんでした。今日は会社のメンバーで三宮(神戸)までお好み焼を食べに行ってました。もちろんビールも飲んでます。確か4杯か5杯ぐらいでしたか(正確には数えてません)。でも、帰宅中はKATSがうまく動かなかった原因が知りたくて仕方がありませんでした。21:30過ぎに帰宅しましたが、すぐにPCを立ち上げてログを確認しました。・・・「PCを立ち上げて」と書いてますが、大引け後にPCを自動シャットダウンする部分はちゃんと動いていたという事です。悪いのは別スレッドでバックグラウンド動作している自動売却部分です。ログを見たり実際にテストしたり。何度も試して原因が数箇所ある事に気付きました。売り注文が発動しなかった根本的な大きな原因が1つ。そしてメールが飛ばなかった原因が1つ。そしてさらに問題は、それらの問題を直した時に発覚した実際の注文処理でのミスです。。。(1)監視漏れ実際に株を購入して保有銘柄に追加されたのは今日が初日でした。なので生きた保有銘柄を使うのは初めて。保有銘柄に追加された銘柄を売却候補銘柄としてローカルDBに保存し、楽天証券RSSで監視スタートさせた時に問題が発覚しました。なんとなんと。保有銘柄一覧に「市場区分(いわゆる市場コード)」が入っていないのです(汗)。GMO証券の市場区分は例えば東証だと「001」など。それを楽天RSSの市場コード「.T」に変換して監視をスタートさせるのですが、保有銘柄一覧を取得した時の市場区分が空だったので間違った名前で監視スタートさせていました。つまり、監視スタートさせたつもりなのに楽天RSSからは値動き等を全く教えてもらえない状態でした。「そもそもどうしてGMO証券の保有株一覧の市場区分が空なんだ！！」と原因を調べました。最初はプログラムが間違っているんだと思ってずっと調べていたんですが分からず。一応マニュアルと見ようと思ってAPI仕様書を細かく確認すると・・・市場区分の説明には「信用建玉の市場区分」とありました。。。保有株の場合は空だと。何故か保有銘柄一覧の中には市場区分がありません。銘柄コードと市場区分をセットでどこかに保管しておくか、あるいは買い注文の約定一覧には市場区分があるのでそれとマッチングして取得するしか方法が無さそうです。多分後者にすると思います。そうしないと楽天RSSの監視をする事が出来ないんです。。。シミュレーションでは自分で保有銘柄を入力してテストしてたので気付きませんでした。この問題はすぐに修正するほど簡単な内容ではないので、早くとも今週末の対応になるのでは無いかと思います。今は暫定的に、全ての銘柄を登録する時に「.T」を付与するようにしました。つまり、東証の銘柄を購入しない限り正しく動作してくれません。東証にした理由は単純に保有株のニイウスコーが東証だから(笑)。明日と明後日は東証に絞って監視しようと思います(^-^;(2)メール送信ミスこれは単純に私の認識漏れでした。売り注文にミスをしようが注文を試みた時にはメールを送る仕組みにしていた筈なのでメールが届かない事は大問題だと思いました。原因は単純で、パーソナルファイアーウォールがネットワークを出ようとしているKATSに対して「許可しても良いですか？」と確認ダイアログを出している状態で止まっていたと思われます。私はKATSを一度アンインストールして再びインストールした時には初回に必ず聞かれるとは思っていたのですが、バージョンを上げて上書きインストールする度に初回は確認ダイアログが出てしまうようです。これは不便。。。まあメールが飛ばないだけなので致命的な問題にはなりませんが注意が必要です。(3)発注ミス今回、本当の保有銘柄に対して本物の売り注文を発注して発覚したプログラムミスがありました。実際は動いていませんでしたが、(1)の問題を解決したまま明日運用しても発注時に不具合が出るところでした。成行注文を出す場合は、注文パラメータで「指値」のところを0円にする為に「0」をセットしていました。でもマニュアルを見ると成行の時は「指値」には空文字をセットしろ、と(汗)。そのバグを直したらGMO証券に成行き売り注文がエントリーされました。もちろんテストなのでその注文はWebから取り消しましたけど。という事でまだまだ実運用でのテストが全然満足に行えていませんでした。しかしながら今回強行ではありますが実際のデータで動かした事によってバグも見つかって修正が出来たので良かったと思います。いよいよ東証限定とは言え、明日は本格的にKATSに動いてもらって売買出来るのでは無いかと期待しています。結果は明日の23:00以降ぐらいに報告する事になると思います。原因調査、修正、テストに2時間半掛かりました。飲んで帰った後は厳しいです(´д｀;P.S.先日オークションに出したAIBOは入札してくれた方が1人いらっしゃいました。金曜日の昼頃に終了ですので欲しい方はお早めに(笑)
Oct 24, 2007
コメント(0)
-
KATSの部分的サービスインが可能に！！
タイトルを見て「はぁ！？」と思われた方、すみません(汗)。KATSとは「KNIGHT's Auto Trade System」の略で、私が開発している株の自動売買プログラムに付けた名前です。知っている人は数名だと思います(苦笑)。カッツと読みますが「勝つ」という意味と私が卓球でカットマンをしているのでそういう意味も込めています。そのKATSですが、ようやく一部サービスイン可能な状態になりました。自動売却部分です。自分の保有銘柄を監視し、購入を感知したら銘柄毎に売却用の監視をスタートします。購入後の最高値から指定された率だけ株価が下がると自動的に売り注文を発注してくれる仕組みです。このシステムのメリットは「利益確定／損切り」をまさに機械的に行ってくれる事で、人間の曖昧な判断による決断遅れが無く、一貫したルールの下で売却を行います。今まで私がメンタル面の弱さにより負け続けてきた事から、ようやく解消されます。これで勝てないとなると、あとは買い注文のマズさによるものだけになるので、自分のトレードを改善させていくのに目標が絞りやすいと思います。朝PCから起動して自宅を出ます。自宅に居る10分程度はPCからも買い注文が可能ですが、それ以降は携帯からの注文になります。GMOインターネット証券は携帯からの注文が優れていないと思っていましたが、実はiアプリが公開されていた事に昨日気付きました(遅っ)。自宅PCでKATSがずっと保有銘柄を監視してくれているので自分は買い注文のみに集中します。あとはお任せ。しかるべき株価で売ってくれる事でしょう。ログ出力もしっかり行うようにしましたし、売り注文を出す時には自分の携帯にメールを送ってくれるように作り込みました。なので自分が買った銘柄をKATSが「トレーリングストップ値○円に対し○円に達したので売り注文を行います。」と知らせてくれるのです。素晴らしい(自画自賛ｗ)。また、大引けを終えたら自動的にPCをシャットダウンしてくれるようにしましたので、帰宅した時にはPCの電源は切れています。経済的～(笑まだ自動売買のうちの売る方だけしか完成していませんが、私の一番実現したかった部分が利用可能になった事は非常に大きいです。是非とも効果を確かめるべく、GMOインターネット証券への引越しを考えようと思います。いくら安いとは言え手数料が発生するので、増資のタイミングを睨みながら時期を検討します。そして引き続き、監視からの自動購入について検討していきたいと思います。・・・こっちは難しそう(滝汗
Oct 20, 2007
コメント(0)
-
自動売却プログラムを試してみました。
実際に購入してそれを売るテストをする事は出来ませんが、仮に保有しているとしてそれをどのタイミングで売るかはシミュレーション出来るので今朝初めて試してみました。試した銘柄は・YOZAN(6830)・ニイウスコー(2731)・オックスホールディングス(2350)・クインランド(2732)・アライドテレシスHLDGS(6835)の5つでした。全て、前日終値で購入して持ち越していたという仮定で登録しました。それを今日、どのタイミングで売るか。まだ時間が来たら自動でプログラムを終了したりPCをシャットダウンしたりは組み込んでいないので、自分が出勤するまでの10分ちょっとしか試せませんでした。その間、YOZANとクインランドは寄付かなかったのでデータが取れず。ボツでした。上から行くとまずニイウスコー。前日終値の7,080円に対し、寄り付きは7,290円。その時のトレーリングストップ値は7,070円。そのまま上昇して行ったので高値更新し、同時にTS値も上昇。一度もTS値に掛かる事無く7,560円に到達し、TS値を7,330円まで切り上げたところでログは終わっています。。。その後どうなるはずか確かめたら、今日の天井7,780円時点でTS値が7,540円に。その後の下落で7,500円になった時に売り注文が掛かり、約定したのは7,430～7,500円辺り。7,080円で保有してたので400円ぐらいの利益を得たとしたら5%の利益確定。なかなか！次はオックス。11,060円で持ち越していたとして、寄り付きは11,500円。TS値は11,150円からスタート。こちらはログに売却タイミングも残っていました。12,400円まで達した時にTS値が12,020円になり、実際は11,920円になった時に売り注文発動です。歩み値を見る感じでは、12,020になってから11,920円になるまでにかなりの約定があり、この遅れはデバッグモードだったからだと思っています。どちらにしてもその付近の安値は11,920円なので、最悪でもこの株価で売れていると思われます。という事で7.7%の利益！最後にアライド。61円で持ち越していて64円まで高値更新。TS値を62円に切り上げたところまででログは終了しています。その後の値動きをチェックすると、その後ちらっと62円で約定しています。その付近の約定がほとんど63円だったのを見ると、成行売りしていても62円で売れていた事が分かります。という事で1ティック抜きになるけど1.6%の利益。・・・これってすごくないですか(^-^;前日終値で持ち越すという想定と、たまたまシミュレーションした銘柄が全てギャップアップしたからという理由ではあると思いますが、非常に良い感じで利益確定出来ているんです。今後もシミュレーションを続ける必要がありますが、これは期待出来そうです♪
Oct 17, 2007
コメント(0)
-
自動売買の「自動売却部分」がほぼ完成！
最近開発に対する意欲がまた再燃してコツコツと作っていたのですが、ようやくそれなりに動くものが出来てきました。GMOインターネット証券にログインし、自動売却のプロセスを実行した時の大まかな流れはこんな感じです。１．ローカルDB(Access)の売却候補銘柄に登録されている全銘柄に対し、 楽天証券のRSSによるリアルタイム監視を行う これは前日大引け時点で保有銘柄が存在し、売れずに持ち越した時に 残っている「売却候補銘柄」に対し、引き続き監視を始める作業です。 リアルタイム監視が何をするかは後述します。２．GMOインターネット証券から、5秒間隔で「保有銘柄一覧」を取得する 5秒間隔なのは、GMO証券の情報取得系メソッドを連続で呼び出すと攻撃と みなされてリクエストを受け付けないので「5秒空けて下さい」というルールが あるからです。ちなみに注文系メソッドはバンバン送って可です。 (1)保有銘柄一覧のうち、売却候補銘柄に無い銘柄がある場合、 その銘柄を売却候補銘柄に追加し、楽天証券のRSSによるリアルタイム監視を行う これは、自分が株を購入した事によって保有銘柄が増えた事を表します。 その時は、初回同様、リアルタイム監視を行います。 ２．の作業は、基本的に大引けまでずっとループしています。楽天証券のRSSによるリアルタイム監視では、次のような事を行います。売却候補銘柄には、購入後高値とトレーリングストップ値が入っています。初回登録時には購入後高値は買い値。トレーリングストップ値は買い値に対する一定率マイナスの値が入ります。その率は設定で変更可能です(今の所-3%で試そうと思っています)。リアルタイム監視で、現在の株価が購入後高値を超えた時にそれを置き換え、同時にトレーリングストップ値を再計算します。逆に、現在の株価がトレーリングストップ値以下になってしまった場合にはGMO証券に成行き売り注文を発行してその銘柄の監視を終了すると共に売却候補銘柄から削除します。以上です。GMO証券に入金していないので実際に購入して動きを確かめる事は出来ませんが、ダミー値を返すテストサーバー上ではうまく動いています。本当のデータでトレーリングストップの部分だけは試したいと思っています。予め、持ち越していたのを想定して売却候補銘柄にデータを登録しておきます。その銘柄をどのタイミングで売るかをシミュレーションする事によってある程度のテストを行う事が出来ると思っています。例外処理やログ出力などでまだ細かく作り込んでいない部分も多いので、それらを整備して自動売却プログラムだけでもリリース出来たらと思います。ただGMO証券は手数料が必要ですし、今の資金ではとても運用出来ないです。増資するタイミングに合わせてという事になるでしょう。楽しみです。その時期が来るまで、しっかりテストします。
Oct 16, 2007
コメント(0)
-
自動売買プログラム開発の進捗(？汗)
うむむ・・・あまり進んでません。。。監視する項目を増やしたり、モード(監視・買い・売り)やトレーリングストップ値(高値から何%下がったら売るか)を保存する仕組み、などなどを作っただけです。手動売買に比べたらあまり見栄えは気にしなくて良いと思うので適当に(?)デザインしてます。こんな感じです。それより、本来注力しないといけない部分以外に意識が散漫している感があります(^-^;例えばこのプログラムの名前を考えました(笑)。最初タイトルには「KNIGHT's Auto Trade Tool」って書いてたと思いますが、覚えにくいし呼びにくいという事で、何か良い愛称が無いか検討しました。で、決定したのが「KNIGHT's Auto Trade Sytem」略して「KATS(カッツ)」です。トレードで「勝つ」という意味も込めてますが、卓球でカットマンをしている事もあるので、この名前にはちょっと愛着が沸いてますｗ名前を決めたのは良いのですが、ついでにアイコンも作りました。オリジナルのプログラムを作っている人は大体格好良いアイコンがあるので。・・・ですが私は本当にこいういうセンスが無いんです。本来ならロゴなり絵なりを考えてデザインすると思うのですがそんな才能が無いので字のみです(汗)。このブログの配色もそうですし私の歴代の車の色もそうなのですが、私は紺色が好きです。Navy Blueを勝手に「KNIGHTカラー」と呼んでいるぐらいです(笑)。という訳で当然アイコンもKNIGHTカラーを基調にしています。・・・駄目だ。。。いらんところに時間掛けてプログラムが進まない(´д｀;形から入ってるし。
Jul 21, 2007
コメント(2)
-
自動売買プログラムの進捗
3連休という事もありますし、連休に入るまでは本を読んでてずっと休んでいたプログラム開発を進めようと思ってました。でも、思っていたよりは進みませんでした。。。まずプログラムの構造から。GMOインターネット証券のAPIについては独立させ綺麗な感じで組んでいたんですが、DDE(DynamicDataExchange)という仕組みで楽天証券のRSS(RealtimeSpreadSheet)経由でリアルタイムデータを取得する部分がメイン画面のロジックとして書かれていたのでいまいちでした。手動売買専用みたいに作られてた部分もあったのでその仕組みを変えると共にメイン画面のロジックから独立させ、DDE処理専用のクラスを作りました。これで再利用可能になりました。また、今まで手動売買用として1銘柄の板情報を表示し売買する仕組みしか用意して無かったのですが、自動売買では監視銘柄が複数になる事によってその処理が複雑になりました。DDEを操作するクラスのインスタンスが銘柄毎に1つ必要なので、複数扱う為には配列を用意するなどの必要がありました。リアルタイムに情報が変化するたびにVBのイベントが発生するのですが、VBの知識の無さもあって配列変数にイベントハンドラを与える方法についても少し悩みました。さらに頭を抱えたのがDataGridViewという仕組みでした。Excel表のようなものが画面の中に埋め込まれたようなものです。さらに、その表はデータベースと連結していないといけません。監視銘柄を登録しておいたりしないといけないので、アプリが立ち上がっている時だけデータを保持していたのではマズいので、DB連携が必要です。で、一番簡単に作成出来るDBとしてAccessを選択しました。個人用DBとしては充分すぎる性能です。純粋なRDBMSとして業務には正直全然使えませんが(苦笑)。このDataGridViewについて甘く見てたのですが、DB項目を表示したり、さらにDBにない列を追加したり、また画面で修正した内容をDBに反映させるのがちょっと慣れないと分からなくててこずりました。ようやく基礎部分は出来て、自分が登録した銘柄の項目をリアルタイムに取得する部分だけ完成しました。あとは手動売買と自動売買の切り替えを行った時にそのデータをどうするかとか、監視をどうするか、とか細かい部分について作り込んだり。なんか周辺部分をああだこうだイジくってたら時間が経って「それほど進んでない」というのが現状です(汗)。このあとは、自動売買のフローについて考えてみようと思います。それが出来ないと適当に作り始めても行き詰ると思うので。今考えているのは、1度に1銘柄しか扱わない方法です。「せっかく自動売買なんだから同時に複数銘柄を相手したら？」と思われるかも分かりませんが、私の知能ではそんな高度はロジックは考えられそうにないのと、資金が少ないのでそんなに分散投資は出来ないと思っているからです。１．スタートした時は「監視モード」です。監視モードとは、前日自分が登録した監視銘柄を監視し「今が買いだ」というシグナルが出るまで待っているモードです。買いシグナルの方法は別途検討します。２．買いシグナルが出たら「買いモード」に入ります。買いシグナルが出た銘柄を基本全力買いで買いに行きます。全力買いの方法については先日日記にも書きましたが考え中です。raicyonさんのご意見を参考にするかも知れません。もしその銘柄の株価が高くなる等の理由で購入不可能になった場合は銘柄を監視候補から削除したあと、監視モードに戻ります。その銘柄がもう買えなくなるまで買います。その間は買いモードを抜けません。３．買いモードで1株でも購入出来た場合「売りモード」に移行します。売りモードは、購入した銘柄の買い値をスタートの高値とし、それから○%下の株価を「トレーリングストップ値」とし、その株価を下回るまでずっと株価を監視します。高値が切り上がったらトレーリングストップ値を切り上げます。トレーリングストップ値を下回ったら、保有株を全部成行売りします。成行き売りが完了するまではずっと売りモードが続きます。もしトレーリングストップ値を下回る事無く大引けを迎えた時は次の日の持ち越しもあります。その場合はそれまでの高値＆トレーリングストップ値を次の日まで持ち回ります。４．売りモードを抜けると、今売った銘柄を監視候補から削除します。その時点で監視銘柄が無くなった場合はアプリを終了します。無くなっていない場合は監視モードに戻ります。５．15:10を過ぎたら無条件にアプリケーションを終了します。・・・動いてても何の意味も無いので(^-^;今考えてるロジックはこんな単純なものです。監視モードが一番難しいかなぁと思ってます。買いモードは工夫が必要かも。売りモードは一番簡単な気がします。当初考えていた7/31納期は、ちょっと厳しいかも知れません(汗)。
Jul 16, 2007
コメント(4)
-
(自動売買)成行買いについての考察
私は自動売買させるなら成行注文が基本だと思っています。スキャルピングなどをするなら指値注文が大事だと思います。「指値で売買する奴は駄目だ」と言う投資家も多いそうですが、私はそうは思いません。ザラバに居て逆張りする時など、指値注文が非常に有効な場合もあると思います。ですが自動売買となると、適切な指値を入れる事は人工知能とも言えるような感覚が無いと厳しいのでは無いかと私は思いました。例えば「この株価でリバウンドしそうだな。今なら自分が注文を入れてその後に板が厚くなる感じがするから今だ！」って感じで指値を入れないといけないと思うので。そういう理由から、私が自動売買を作るなら売買注文は成行で入れる予定です。いや、入れる予定でした。売り注文に対する考えは今も変わっていません。でも買い注文に対しては「本当にそれがベストか？」と疑問に思っています。何故かと言うと、成行買いをする為にはその銘柄のS高の購買余力が無いと注文出来ません。資金の少ない私は、必然的に購入可能株数が減ります。それどころか、低位株なら注文すら入れれない状態も有り得ます。バナーズを例に挙げると、現在37円ですが成行で100株買うためにはS高の67円分必要なので6,700円が必要です。私の今の資金では成行買いだと200株しか購入出来ないのです。普通に37円で注文を入れたら400株の注文を入れれるのに。この問題を打破する為に頭の中で思考を巡らせました。例えばある程度高い値段で指値を入れて実質成行っぽく買う事。40円で指値とか入れたら恐らく買えるでしょう。でも、値動きが速い銘柄だと、一部約定のみで置いていかれるか、あるいは一つも約定しないまま放置されるかも知れません。「う～ん、どうしたものか」と悩んで、ふとひらめいたのがこんなロジックでした。値動きが速い例として今日のYOZANの板(大引け)を例に出します。現在値が1123円で、その時に「買い注文を入れよう」という事になったとします。仮に200株の買い注文を入れる事になった時、一番安い売り板の1129円の指値で200株の買い注文を入れます。全約定すればそれで終わりですが、一部約定でまだ全部の注文が終わっていない場合は、その時点での一番安い売り板に変更注文します。もし1130円なら1130円に変更します。変更が通ったら全約定するかも知れませんし、また一部約定かも知れません。一部約定ならまた先ほどのロジックを繰り返します。もう1つの可能性として「注文変更したら余力が足りなくて変更出来なかった」になる可能性があります。その場合は残りの買い注文を取り消すという処理に流れてこの買い注文を終了します。待っていたら値下がりして買えるかも知れませんがそれは考慮しません。・・・文章で書くと非常に分かり辛いと思います。お伝えするのも難しいのですが、ちょっとフローにしてみます。(1)ある銘柄を「購入する」という事になる(2)一番安い売り板の値段を確認。購買余力をこの値段で割り、購入可能株数を算出。(3)買い注文を出す(4)注文がどうなったか確認する。 a)全約定の場合、この買い注文を終了する b)一部約定、あるいは全く約定していない場合はそのまま(5)へ(5)一番安い売り板の値段を確認。現在出している注文がこの株価かどうか確認。 もし違うなら株価の変更注文を出す。同じ株価ならそのまま。(6)変更注文が受け付けられない(この間に全約定してしまったか、あるいは 購買余力が足りなくて変更出来なかった)時には、この買い注文を終了する(7)注文がどうなったか確認する。 a)全約定の場合、この買い注文を終了する b)一部約定、あるいは全く約定していない場合は(5)に戻る先ほどより分かりやすくなったでしょうか！？もっと分かりにくくなったでしょうか？(汗この方式、私独自の発想だと思っているのですが「そんなの自動売買の世界じゃ常識」とおっしゃる方はどうぞご指摘下さい。勉強し直します。まるで成行注文のように指値を動的に変更させながら全約定の方向に持って行くので私は「成行指値買い」略して「成指買い」と命名しようと思ったんですがどうでしょうか？ｗ自動売買で買い注文を出す時にはこのロジックを使ってみようかと検討中です。
Jul 9, 2007
コメント(2)
-
自動売買計画の進捗
この休みは先週まで続いていた話題の練習も終わり、また卓球の試合等も入っていないので開発に集中する事が出来ました。お陰様でいつもよりはかどっています。GMOインターネット証券WebサービスのAPI呼び出し自分が使用するAPI呼び出しメソッドは全て作成出来ました。・ログイン・ログアウト・購買余力取得・注文・注文一覧取得・注文変更・注文取消・約定一覧取得の8つです。その他のAPIは信用取引に関するものなので今の所作成する予定はありません。設計変更各画面で持ち回る情報等について、今まではメイン画面に持たせたり、統制が取れていませんでした。今回そういう情報を一元管理するようにしました。ログイン処理中でベタ書きしていたユーザーIDやパスワードもこの情報に含まれるようにし、監理しやすくしました。またGMOインターネット証券にアクセスすると購買余力が無かったり保有銘柄が無かったり等で全てのテストが出来ないのでローカルにテストAPIサーバーを立ち上げてテストするのですが、本番環境とテスト環境をチェックボックスのオン／オフで切り替えるようにして開発効率を上げました。注文画面基本構成は板情報と同様、マケスピのパクリです(笑)。買い注文の時には購買余力を元に「全力買い」するように注文数量を計算して初期表示します。成行の場合は現状では単位株数を初期表示しますが、理想としては購買余力で値幅上限を買う時の購入可能数量を初期表示させたいです。注文画面の「現在値」とフラグ等のみ、マケスピと同様にリアルタイムで更新するようになっています。現時点での画面イメージはこんな感じです。メイン画面に見えている「注文一覧」「約定一覧」のボタンは動作確認テスト用で、最終的には開発環境との切り替えチェックボックスと共に削除します。今の所ここまでです。手動売買についてはもう完成に近づいていると思われそうですが、実際は売り注文がちゃんと出来てません。板をダブルクリックして買い注文同様にポップアップを出す事は出来てますが、本来なら保有株一覧を取得してそのうち指定した銘柄の分の株数を取得し、そこから今発注済みの売り注文の株数を引いて初期表示する必要があると思いますが出来ていません。また、注文変更や取消の画面を作成していません。何だかんだ言ってもまだ完成には遠いです。ただ自動売買なら「買い注文を出したら、その注文が全約定したのを確認して全売りする」という単純ロジックで呼び出し可能だと思っているので、手動より自動の方が作りやすいのではないかと思ってます。問題は買い注文のタイミングですが。。。
Jul 8, 2007
コメント(0)
-
自動売買計画の進捗
一昨日進捗を書きましたが、仕組みに納得行かなかったのでちょっと作り変えました。XMLを扱っているという事すら隠蔽するために、応答メッセージは全てクラスでもらうように作り変えました。ログイン処理とログアウト処理はステータスとメッセージしか返って来ないので、その2つの属性を持ったBaseResponseというクラスを作り、ログインとログアウトはそのクラスが返って来ます。注文等、その他の要求に対しては先の2つの属性に加えて、要求内容に応じた結果を返します。なのでそれらの応答メッセージはBaseResponseのサブクラスとして作成。例えば注文を出した結果はOrderResponseクラスを返し、このクラスはBaseResponseを継承しています。仕組みを作り変え、呼び出し側もすっきりと使えるようになったので、買い注文と売り注文のメソッドを作成しました。非常に簡単に作成出来ました。ちゃんとデザインした賜物でしょう。他にも色々と作らないといけないメソッドがあります。購買余力問い合わせ、注文変更、注文取消し、注文履歴問い合わせ、保有銘柄一覧問い合わせ、約定履歴問い合わせ、・・・などです。今のところ、信用取引に関する部分は作成しない予定です。これらは結果データをクラスに詰める部分が今までより多いのでちょっと厄介ですが、力技なので時間があればすぐに出来るでしょう。せっかくWebサービスのAPIを呼び出す仕組みが少し出来上がったので、先日作った板情報からの手動売買の画面から少し呼び出してみる事にしました。「GMO Login(仮)」というのはテストするために付けたボタンなので無視して下さい(笑)。板をダブルクリックすると注文用ダイアログがポップアップで開きます。マケスピ風です。今回はその画面は紹介しません。まだ完全に作ってないので。画面は、仮に売り板をダブルクリックした結果です。ちゃんと(?)売れる株が無い事がメッセージ表示されています。当たり前ですね。まだ入金すらしてない口座に保有銘柄がある訳無いので。。。やっと手動売買のスタートラインに立ちつつある状態です。でもまだまだです。まだ作ってないAPI呼び出しを作ったら、次はトレーリングストップ売り注文を手動で出せるようにする事です。そこまで来て、やっと次が自動売買なのです。道のりはまだ長い。
Jul 5, 2007
コメント(4)
-
自動売買プログラムの進捗
情けない話ですが、やっとVB2005のプログラムからGMOインターネット証券のWebサービスAPIを使って認証されるところまで作成出来ました。実現出来たのはログイン処理だけです。VBからHTTPリクエストやレスポンス、クッキーなどを扱うクラスをどうやって使うかについて検討したり、実現方法は色々あるのでどの方法にするか悩んだり、あともう1つ大きいのは「一応ITの人間なので『動きゃいい』ってのは許せない」から、拡張性やメンテ性に優れた設計にしたくてデザインを試行錯誤してたってのもあります。具体的に書くと、GMO証券のWebサービスのAPIは全てGmoProxyというクラスに隠蔽し、このクラスを扱う側はGMO証券のAPIを全く知らなくても利用出来るようにしてます。ログインや発注、約定履歴の照会など、各サービスに対してメソッドを作成します。例えばpublicなメソッドとして今回作成したLogin()メソッドがあるのですが、呼び出し側はユーザーIDとパスワードを渡して呼び出すだけです。内部では、ログインサーバーにHTTPリクエストを投げて認証サーバーのURLをもらい、リダイレクト。認証準備のレスポンス(XML)を取得します。XMLで準備OKを確認すると、今度は認証用URLを生成し、認証準備のレスポンスに含まれるクッキーを引き回して、ユーザーIDとパスワードをパラメータにしてHTTPリクエストを投げてリダイレクトし、認証結果のレスポンス(XML)を取得します。こんな流れですが、結構ややこしい手続きを経てやっとログイン出来ます。この中で、HTTPリクエストを送信する処理が出て来ますが今後も違うメソッドを作る時にも必ず行う処理ですので、メソッドで外出しして再利用可能にしています。また、HTTPレスポンスで返されるXMLからデータを取得する部分についてはXmlUtilというクラスにして責務分割したりしています。もしログイン処理というメソッドにダラダラとコードを書いてしまうと、後々死ぬ事になりますから。ここまでやってると、今度発注やその他のメソッドを作る時に非常に楽になります。WebサービスのAPI系処理はまず1つ出来たので、ちょっと回り道(?)して、今度は「毎日Webサービスを使用する為に利用設定をしないといけない」部分について、わざわざWebサイトにログインして操作しないといけない作業を自動化しておこうと思います。
Jul 3, 2007
コメント(4)
-
GMOインターネット証券の口座開設
やっと開設。。。先ほどWebサービスAPIの仕様書と開発用擬似Webサービスサーバーをダウンロードしました。納期を決めないとなかなか進まないと思うので宣言します。7月末納期で自動売買の仕組みを作ります。目標としては8月から毎朝プログラムを起動して出勤する事。GMO証券のWebサービスは毎日Webサイトにログインして利用設定を行わないといけないとの事。セキュリティを考慮しての事だと思いますが、これが面倒臭そう。。。まぁこの部分だけWebサイトの操作をするプログラムを書いて自動で動かせば良いのかも知れませんけどね(^-^;では進捗があれば日記に書きたいと思います。明日も卓球の試合で朝早いのでもう寝ます・・・おやすみなさい。
Jun 30, 2007
コメント(0)
-
自動売買への道のり
自分の中に、何ステップか段階があると思っています。(1)リアルタイム株価の取得今はPCだとマーケットスピードによって実現しているリアルタイムでの株価監視。自宅を出てからだと携帯でiスピードやハイスピードα(松井証券)で監視しています。今回、自作プログラムでリアルタイム株価を取得する部分については実現出来ると見ています。実際、マケスピに似せた画面でリアルタイムに板を出す事は出来ました。※ちなみに数値のバックが紺色なのはオブジェクトがどこにあるか把握する為で、 実際完成の時には分からないように背景と同じ色にするつもりです。 また「現在値」など必要なデータが無いのも開発中の画面だからですしかし、こんな事が出来たとしても何のメリットもありません。メリットを出す為の前段階です。普通に監視するだけならマケスピの方が遥かに優れています。(2)リアルタイム情報からの手動注文上のプログラムで板をダブルクリックしたらマケスピのように注文画面が立ち上がって注文出来るようにしたいと考えています。発注部分はGMOインターネット証券の口座が開設出来てからなのでまだですが、ダブルクリックした時にそのイベントを取得する部分までは作っています。ここまで出来たらメリットがあるのかと言われたら、一応あります。出来る事は楽天証券と変わりないですが、何が嬉しいかと言えばGMO証券は楽天証券に比べて手数料が遥かに安いです。近い機能が実現出来ればそれは充分にメリットがあると言えるんです。さらに自分なりに便利な機能を付けるとしたら例えば「全力買い」機能。自分の購買余力限界だと何株買えるのかを自動計算して株数にデフォルト表示しておけば基本全力買いの私にとっては注文スピードは格段に上がるでしょう。(3)トレーリングストップ機能次に考えたいのがトレーリングストップ機能。GMO証券には逆指値注文がありません。なので逆指値注文を独自に実装するしか無いです。楽天証券などなら逆指値注文として発注します。でもそうではなくて、逆指値条件に掛かるまで監視し、条件に掛かったらその注文をすぐに執行するようなプログラムを組む必要があります。そのついででは無いですが、対象銘柄の高値が上昇するに従って逆指値条件を勝手に切り上げるようにしてあげるだけで、トレーリングストップ機能が出来上がります。トレーリングストップ売りは私の求めている非常にニーズの高い売り注文です。これが出来たらメリットは大きなものになるでしょう。(4)自動売買(3)で自動監視の売り注文が発注出来るようになったら、あとは購入後にそれを呼び出すだけでよくなります。という事は、買い注文も自動化出来ればある程度全自動で売買を行ってくれるはずです。購入条件やタイミングというのは非常に難しいロジックになると思いますので困難を極めるでしょう。最初の段階は実際発注せずに、シミュレーション的に「どの銘柄をどのタイミングでどんな注文を出すか」というログだけ出力しておき、帰宅後にそのログを解析して「このロジックで良いのか」という風にしばらくデータを取ってチューニングしてからの実運用になるでしょう。本当にお金を扱う時にめちゃくちゃな事をされたら困るので。(5)携帯からの操作自動売買が出来て、それが理想的な売買を行うなら要らないかも知れません。でも時には自分で売買したい時や自宅を出た後でトレーリングストップの条件を手動で変えたい時などがあるかも知れません。また出張等で自宅を空ける時にも遠隔操作で売買スタートやストップが出来れば言う事はありません。そんな夢を実現させる為には、携帯からのリクエストを受け付けるサーバーが必要でしょう。発注に関して私が思いつくのは、JVMが動く無料レンタルサーバーを借りてそこにServletを置いて、GMOのAPIを呼び出すようにすれば可能かと。勝手に動いてる自宅PCの売買プログラムとの関係をどうするか色々検討が必要ですが。この構想が夢物語にならないように、少しずつですが着実に進んで行きたいと思います。今は(1)段階。早くGMO証券と連携したいです。
Jun 25, 2007
コメント(4)
-
GMOに期待過剰だった！？
まだ仕様書を見た訳じゃないのでAPIの詳細は分かりませんが、ネットで色々なWebサイトから情報収集した感じでは、GMOインターネット証券はAPIで売買の発注や自分の余力、売買履歴の取得等は可能ですが、もしかしてリアルタイムの株価が取得出来ない！？そんな・・・致命的すぎます。確かに発注機能は確実で良いものになりますが、そのトリガーをどうする！？(汗楽天証券のRSSを使って株価を取得して判断させ、それをトリガーにしてGMOに発注を掛けるという手段を取っている人が結構いるようです。そんな事するならHTTPリクエスト飛ばして楽天証券を操作するけど。。。(汗Excel/VBAの中にそのまま楽天証券Webサイトの操作を書いた方が良かったりして(´д｀;そんな私はVBとかVBAが苦手です(ぁぅとりあえず検討を継続します。。。
Jun 18, 2007
コメント(5)
-
株の自動売買について ～その２～
「その１」で書いた通り、ずっとザラバに張り付いている専業トレーダー以外の人がデイトレで確実に利益を得る為には、自動売買が欠かせないと思っています。私は、プログラムに株の売買を自動で行わせるには、証券会社がAPIを公開していない限り不可能だと思っていました。で、私の知る限り(ろくに調べもしないで)APIを公開している有名どころの証券会社は「全く無いだろう」という結論に達しました。なので、売買プログラムというものに関してあまり具体的な感情は抱いていませんでした。でも最近「もし開発出来るならその方法を考えてみたい」と思うようになりました。APIが公開されていないとすれば、私の頭の中に浮かぶ自動売買の手段は2つでした。※注：ここから結構マニアックです(汗まず1つ目は、WindowsAPIをゴリゴリ呼び出すか専用ツールを使ってキーボードやマウスの動きを再現し、証券会社のWebサイトや売買ツールをプログラムに操作させて売買を行う方法です。私の知識が浅はかで間違っていたらご指摘願いたいですが、この方法はプログラム起動中に想定外の動きをした時(例えば予期しないポップアップが上がったり、自分が操作する事により間に違う処理をしてしまったり、等)に間違った処理を行ってしまうのでは無いかという気がしました。特にマウスの動きを再現するような場合はウインドウの大きさなどによっても左右されそうで恐い感じです。キーボード操作のみを再現するのなら正確性は高いと思いますが。もう1つの方法は、売買ツールの操作は不可能ですがWebサイトの操作を行う方法。でもこれはキーボード操作を再現するのではなく、HTTPの操作を行う方法です。あるURLに対してどんなパラメータでリクエスト送信するというのをプログラムし、HTTPのプロトコルを使ってWebブラウザになりきって操作するものです(多分)。まだ深く調べていないですが、この方法は不測の事態は起こりにくいと思いました。実現するには「Jakarta Commons HttpClient」というコンポーネント等で可能だという事です。JakartaプロジェクトはJavaをご存知の方には超有名なオープンソースのプロジェクトです。特に私が嬉しいのは、このコンポーネントがJavaで出来ている事です。私はIT業界の人間ですが、唯一人並み(?)にプログラミング出来るのがJavaなので、Javaでコーディングしたプログラムで自動売買出来るならこんな嬉しい事はありません。購入に関しても自動で行うには私のスキル(プログラムに関しても、銘柄選定と購入タイミングのアルゴリズム設計に関しても)じゃ到底企画倒れになると思います。なので、買った銘柄を売るという部分だけを自動で行うプログラムをまず作ろうと思いました。購入した銘柄の証券コードと購入額、株数を入力します。そして「高値の何%(あるいは何円)下になった時に成行き売りするか」という数字を入れ、プログラムを実行。するとプログラムがトレーリングストップを行ってくれる、というものです。1,000円で購入し、200円下を売りラインに設定すると、まずは逆指値注文で800円を注文します。株価が下がり800円に達したら損切り。仮に上昇したら、その上昇を監視して逆指値注文の訂正注文を順次行います。例えば1,300円に上がったとしたら逆指値は1,100円に切り上げている筈です。もちろん、下がった時には下げる事は無いので、最低でも1,100円で売る事になります(成り行き売りなので予想外の株価になる事はあるかも知れません)。トレーリングストップでの売りを自分の作ったプログラムが自動で行ってくれるのです。各証券会社でWebサイトの作りが違うので、プログラムは証券会社毎に必要でしょう。でも発注する部分だけ再利用可能なクラスにしておけば骨格は全く同じものが利用出来て、証券会社を乗り換える事があっても一部のクラスだけ再作成すれば使い回せるのでは無いかと。・・・ここまでが、今日の夕方までの構想でした。今日の夕方に「その１」を書いた時までは「Jakarta Commons HttpCLientを使用して松井証券のWebサイトを操作し自動売買するプログラムを作成します！」と今回宣言するつもりでいました。しかし「その２」を書くに当たり、ちゃんと「APIを公開している証券会社」を調べておかないと論じる事は出来ないと思い、調べてみました。それまでは「APIを公開している証券会社もゼロではないものの、やたらと手数料が高い等で個人は実用的ではない」と思っていました。・・・しかしその認識はズレていたようです。。。GMOインターネット証券がAPIを公開していると知ってびっくりしました。しかもこの証券会社、手数料が松井証券より安いじゃないですか(汗)。なぜ今まで注目していなかったかと言えば、逆指値注文が無かったからだと思います。でも、自動売買が可能なら「○円以下になれば成行き売り」は自分で出来る訳ですから、いちいち逆指値注文をしなくてもプログラムが逆指値を意識すれば良い訳です。APIはWebサービスとして公開しているそうです。XMLやHTTPベースのプロトコルでアクセス可能です。WebサービスならJavaでも扱えます。「Webブラウザ画面を経由せずにGMOインターネット証券の発注機能を利用可能」という事でWebサービスの知識さえあれば自分自身で取引ツールの作成が可能です。これはすごい！！！！機能詳細は会員ページを見ないといけないという事で、まずは口座開設しない事には何も始まらないようです。仕様書や開発ツールがダウンロード出来るようです。Webサイトに開発イメージの画像が掲載されていますが、その画面がMicrosoft Visual Basicなのがちょっと気に掛かる部分です。VBって・・・もう忘れたし(汗)。でもWebサービスはAPIさえ公開されていたらJavaから呼び出せるはずなので仕様書だけ見てJavaで組む事は可能だと思います。とにかく口座開設、口座開設。。。今までほぼ諦めていた自動売買が現実的になって目の前にあります。購入後に放置して運任せのトレードをしていた自分を、自分の専門分野であるITで救済出来るなんて夢のようです。この夢のような計画が近い将来実現出来る事を信じて、やってみようと思います。さて・・・口座解説申し込み、と。。。
Jun 17, 2007
コメント(5)
-
株の自動売買について ～その１～
私は会社員です。「会社員がデイトレなんて！？」という意見があると思います。確かにサラリーマンや忙しい主婦の方など、ザラバに張り付いて居られない人がデイトレをするのは非常に困難だと思います。デイトレはその日のうちに手仕舞いするのが基本の短期売買ですので、売買タイミングが非常に重要になります。なのでそのタイミングをリアルタイムに監視出来ない会社員が「なんでデイトレなんて出来るんだ」という事になります。おっしゃる通りです。実際私は9:00～9:10ほどはリアルタイムで監視していますが、その後PCの電源を切り、操作を携帯に移して自宅を出ます。そして職場に着く10:00前までの間は通勤中に携帯で売買。その後は実質放置です。12:15を過ぎると昼休みに入るので後場が開始するまでに少しだけ操作の時間があります。その後、天気が良ければ野球をしてますので、13:00前に一度チェックするぐらいでその日の操作は終了。その後の約定も運任せという状態です。こんな半放置状態で、デイトレで安定して利益を上げる為には、ある程度自動売買が出来ない事には話にならないと思っています。なので、私は証券会社選びの条件として「手数料が安い」と同じぐらいの重要度で「逆指値注文が出来る事」をあげています。現物買いをした銘柄の売り注文で逆指値注文を利用する事を考えます。このチャートは日中足チャートを表すとします。株価a円でこの銘柄を購入したとします。売り注文は逆指値注文を行ったとします。逆指値売りは「株価が○円以下になったら売り」なので、aより安い株価じゃなければ注文が即執行されます。ここでは仮にe円を損切りラインに設定したとします。これで損失が理論上「e円-a円」より大きくならない事が保証されたので、これはこれで意味がある事です。いわゆる塩漬け状態にはならない訳で、その日の株価がe円まで下がらない限りこの銘柄は持ち越される事になります。もし株価が上昇してa円より高く引けていたとしたら、次の日の逆指値注文はa円より高く設定し、いくら下がっても利益確定出来るようにするでしょう。毎日の終値ベースで勝負するスイングトレードのような手法ではこの方法も有効だと思います。でもデイトレぐらいのスパンだと、これじゃあ効率が悪過ぎる過ぎる可能性があるのです。例えば上のチャートが当日の動きだとすると、いくら株価が上昇しても売れず、最終的にe円で損切りしてしまうハメになります。これじゃあ何の意味もありません。。。そこでさらに利益を取りやすくする方法として、楽天証券なら「逆指値条件付き通常注文」というのがあります。他にもW指値、あるいは追跡指値など色々な呼び方があります。平たく言うと、利益確定の売り注文を指しておいて、それに加えて下がった時の損切り条件も入れる事が出来るという注文で、損失を最小限にとどめながら利益確定も積極的に行う事が出来る、逆指値注文にプラスアルファされたようなものです。例えばe円での逆指値条件を入れつつ、b円で売り注文をしたとします。すると株価がb円を超える時には確実にb-a円の利益を出す事が出来ます。しかも予想に反して株価が下がった時も、e-a円の損失に限定する事が可能です。逆指値注文や逆指値条件付き通常注文を「自動売買」と呼ぶ方が居ます。いや、確かに自動売買です。自分がザラバに居ない間に勝手に損切りをしてくれるのですから。でもこれじゃあ効率が悪いのです。意志が弱くて損切り出来ない人に対して無条件に損切りしてくれるこの注文は非常に有効です。但し、効率の良い利益確定をするにはあまりにも勘に頼る事が多くなるのです。上のチャートのa円で買ったとして、損切り条件はe円。そして売値をb円やc円、d円にしていればb円やc円で売れます。ただ、後から振り返ってb円で売った人が大満足出来るでしょうか？d円で売った人は良かったと思いますが、それは勘が当たっただけじゃないでしょうか？その日の高値を予想する事は難しい事です。下手をして売り注文を今日の高値より高い株価に設定していたとします。このチャートの例だと、ザラバ中ずっと買い値を上回っていたのに大引け前の下落で損切りしてしまうのです。こんな結果に終わったら後悔し切れません。。。「神と悪魔の投資論」という本にありますが、人は利益の出ている時にそれをすぐ確定したがり、損が出ている時には損失を確定したがらないという心理傾向があるそうです。小さな利益ですぐ売ってしまい、小さな損の時は売らずに損失を拡大させてしまうという事で、まさに「勝率は悪く無いが資金がどんどん減ってしまう」という悪循環にハマるパターンです。それを打破するためには、利益が増えていく間は売らず、下がり始めたら売るという法則に従って売買すれば勝率5割、いやもっと低くでも充分な利益を得られる可能性があるそうです。その法則に則っている手法が「トレーリングストップ」という手法で、何度か日記にコメント頂いた事がある「1号機さん」に名前を教えてもらいました。私が過去に日記で書いた事がある表現だと、売り注文の逆指値条件を株価の上昇に合わせて切り上げて行くという手法です。6/11のクインランドの売り注文ではそんな事が出来ました。しかしこの方法もリアルタイムに株価を見てこまめに逆指値注文を変更しないと不可能なのでサラリーマンが確実に実行するのは難しいと思います。私の理想なんですが(苦笑)。ちなみにトレーリングストップはカブドットコム証券で採用されています。他の証券会社でも採用されたら即使いたいのですが、悲しいかな私の資金では手数料体系が厳しいので無理です。トレーリングストップが可能だと仮定すると、上のチャートで例えばb円で購入したとしてもc円で売れるかも知れないですし、c円で購入してもd円で売れる可能性があります。・・・もっともc円で購入した後はその後の下げで損切り条件に掛かる可能性が大きいので一概には言えません。この辺は逆指値条件を株価(高値)にどれぐらい近づけるかという「距離感」に左右されるもので、なかなか正解は無いと思います。人によって意見もさまざまでしょう。それに監視は個々が勘所で指定すれば良いのかなぁと思います。さてここで、トレーリングストップ注文が不可能な証券会社でどうやってこの方法を実現するのかという話に続けたいと思います。ですが長文を打つのに疲れましたので、これは今晩あるいは明日以降に「その２」という事で書きたいと思います。こんな取りとめも無い長文を最後まで読んで頂いた方、どうも有難うございました。
Jun 17, 2007
コメント(4)
全87件 (87件中 51-87件目)
