こちらへ引っ越します。

[0回]

多通貨、多指標のテストをMT4で実施しようとすると、
ほぼ不可能（ファイルやMarketInfo関数、DLLなどを駆使すれば可能だが・・・）だ。

実際に作ってみたのだけど、バックテスト時間が膨大に掛かり現実的ではないと判断した。
そもそも多通貨指標（Ku-Powerなど）をバックテストで利用すると、
バックテスト終了時のチャートオープン時に大量のKu-Chartがサブウィンドウに展開される。
iCustomの呼び出し毎にサブウィンドウに追加されているとしたら、各バーごとの計算量は恐ろしいことになっているはずで、その可能性が高いと思われた。

悪あがきは色々したのだが、どうやってもバックテスト時間が長すぎるため、MT4の継続利用は断念した。
そこで円滑なトレードシステム開発のため、経験の長いJavaでバックテスト機能を開発することにした。
他市場の多指標も使えるし、多通貨の指標も使える。
インディケーターの実装も自分で行う必要があるから、勉強にもなるし、いいことづくめだ。

そもそもMQLでは難しかった単体テストの領域も
Javaであれば、Junitにより容易だ。


いったん、最低レベルの目的地点まで到達できた。
1テスト20分以上かかっていたテストが、15秒程度で完了するようになった。


作ってみて思ったのは、スクラッチであるメリットについて。
スクラッチなのだから当たり前だが、バックテスト結果の統計情報として、
様々な情報を計算して出せるため、多角的な視点から諸々の情報を俯瞰できる。

資産残高のHWMの未更新期間、シャープレシオ、平均保有期間など。

[1回]

ティックフィードの再構築中。
mt4 →dll→（ソケット）→サーバまでの一連の流れの実装が一巡した。
ソケットプログラミングは初めてだったが、形にはなった。
例外検知については、調べれば調べるほど奥が深いことがわかってきた。
今の所、実装出来たものとしては、mt4 とフィードサーバの疎通監視のみ。
mt4 とブローカーとの疎通監視はまだ出来てない。他にも気になる例外検知はまだ実装出来てないし、そもそも事象に対する理解もイマイチ。

フィードサーバの環境見直しをしていたところ、メモリ8gであるべきところが4gしか認識していなかったので来週直したい。

nuroに回線を変えた。満足いく速度が出た。回線工事まで1ヶ月以上待ったがその価値はあった。

mt4 稼働サーバは有線LAN環境に移行したい。時間が足らず、無線LAN環境にて今週は乗り切ろうと思うが、先述の切断検知のテストとして割り切る態度も必要か。

今回、フィードに関する実装はとにかくプロジェクトごとの責務を細分化し、クラスにおいても細分化した。
命名が適切であればあるほど、設計記述は省けるはずだから、ここはもっと詰めていきたい。
マルチスレッドプログラミングも行なっているが、フィード受信スレッド、永続化スレッド、切断監視スレッド、マネージャスレッドなどに細分化した。まだまだ増えるだろうが、適切な命名を心掛けたい。
コードを読むより、パッケージと名前を読ませることで、何をしているかを示した方が良いだろうと考えている。将来の自分が見た時にどこで何をしているか分からないコードにはなんの価値もないだろうから。

[0回]

ここ数年は、私生活でいろいろ変化が激しかった。
人生の重要なイベントが１巡した。

時間ができたとは中々言いづらいが、シストレ（実際はシステム構築だが）を再開しようと決心した。
はっきりいって、仕事にまじめに従事していれば生活できる収入はできるし、特に仕事が辛いというわけでもない。不満がないわけではないが、不満を溜め込む性格は矯正し、いかに自分が変わるか、いかに自分の存在感を出し、価値を認めさせるか、そういった働き方にシフトしている。

シストレに関して今までやってきたことが、何の意味もないことは理解したくらいには成長した。ラッキーパンチが当たっただけの素人が勘違いしていたことも痛感している。

これまでここで書いてきたことは無意味とまでは言わないが厚みのない記録だ。だから、新しい場で成長した自分として、記録を残そうかとも思ったが、やめた。
過去を認める意味も含めて、ここで新たな姿勢で記録を残していく。


さて、今後の計画だが、やはりティックデータの収集をしたい。
理由はいろいろある。
ティックベースのシステムの開発をしてみたい。
自分が勝てるフィールドは必ずあるはずだ。そこを探す。

以前に構築したMT4-DDL(JNI)-Java(RMI)のティックフィードシステムだが、RMIを採用した理由はC言語を極力やりたくないという逃げの姿勢が前面に押し出たものだ。
JNIやRMIという本来不必要なものを利用しており、冗長というほかない。
Java側のソースコードも汚く、後から見るとどこで何をしているのか分からない、クラス分割も甘い、情報の取り扱いも冗長と無駄と複雑の積み重ねのようなプログラムとなっていた。
結局、人（私）がバグっているから、良いシステムが作れなかったということに他ならない。
これは、捨てる決心をした。

だが、ティックを取り扱うメインのシステムはJavaとしたい。
長年使っているeclipse上の開発が自分にとって開発コストの面でメリットとなるからだ。


ティックデータの収集方式については、理想はTCP/IP通信ベースによるFX業者システムへの接続、フィードの収集だが、今のところあらゆるハードルが高いため断念している。

上記の事情もあり、以下の構成を検討している。
MT4（DLL）→ソケット→Java→DB

基本的な実装コードの検証はできた。
１０万件連続送信しても２ミリ秒程度というレベルであるため、速度的には問題なさそうである。

異常検知系が経験的にも弱いので、ここをどこまで詰めるかという話になってくる。

[0回]

さらなる安定化を目指しメモリ増強に着手。
なぜか、認識はされるがハードウェア予約済みとなっており、OSの手元にいかない。
msconfigのブートオプションのメモリ最大値のチェックを外してみる。
起動しなくなるw
しかも、BIOSから。

メモリを元の4G2枚挿しにし、起動。
BIOSは起動したが、OSは起動しない。
何度か試行すると、OSがセーフモードで立ち上がる。
そこからバックアップドライブよりイメージ復旧。

ここから格闘すること3日ばかり。

ハードウェア予約済みとなっていた理由は、どうも、メモリの一部をRAMディスク化していたせいだったようです。
RAMディスクを解放し、再起動すると増強したメモリの認識に成功しました。

いやはや、外付けバックアップドライブにバックアップがあって九死に一生を得ました。

[0回]

先週の途中でCPU高騰が再発。
再び再調査。
DLLからJNIゴール後のjstring型を解放していなかったために、一定以上の生成数を超えるとCPU使用率が高騰していたことが分かった。

これを修正し再稼働させたところ、金曜夜においても問題なく稼働した。
金曜においては、CPU使用率がそれぞれのターミナルで4,5%の推移、メモリはそれぞれで500MB以下で推移した。

今後はフィーダーの安定稼働を目指しつつ、分析や検証の体制を作りたいところ。グラフィカルな分析環境を作れればモチベーション維持にも役立てられるのでそこは重点的に進めたい。

[0回]

一週間稼働してみたが、まだまだコントロールしきれていない。
少なくともＲＭＩ関連のエラーは出なくなり、
フィード受信経路とＤＢ接続経路は安定的に接続できている模様。

稼働の結果、一点問題が発生。
3つほどのブローカーのterminal.exeを稼働させていたが、1ブローカーのterminal.exeのＣＰＵ使用率が高騰。
原因は不明。
少なくともＣＰＵがcore i 7であるため、処理量に依存したＣＰＵ高騰ではない可能性が高い。
処理待ちとグローバル変数の参照を実装したために問題が起きている可能性が高い。

よって、来週は処理待ちを組み込まない実装を以て迎えたい。

[0回]

9か月振りに少しアイディアが出来たので再開。
売買は一切していません。
スマフォげーと格ゲーばっかりやっていて、
残業もしていないのでワープア入りを果たしそうなため、
そろそろ戻りたいところ。勝てるのかは不明だが・・・

前回の記事で出たエラー群はおそらくノートＰＣとＮＵＣＰＣ間の通信切断が原因。
ＮＵＣＰＣ側に余った無線ＬＡＮ機をコンバータで接続したので、
明日から再稼働してみて様子を見たいところ。

[0回]

例外発生時にメール通知が出来るよう
GMail連携を作りjarに組み込んで一週間稼働させた結果。

以下の例外が発生した。

①com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:　・・・1回発生

[0回]

[0回]

開発環境は十分整ったところで問題が発生した。

手持ちのPCとして、IntelNUCとノートPCがあるが、
開発はIntelNUCで行い、
遊びにはノートPCで行いたかった。

ティックフィードは開発機であるNUCに切り替えて継続したかった。外付けHDDもこちらに接続した方が都合がよかった。
しかし、開発機に切り替えたところメモリがまったく足りなかった。
８G中ほぼ7.8Gは占有していたかと思う。
コミット周期を短くすれば解決しそうだが、記憶媒体に負担を掛けたくないので、
その選択は出来なかった。

ノートPCはもともとガチなPCが欲しくて買ったものだ。
かなり高スペックでメモリは32Gb積んでおり、CPUもi7を載せている。

つまり、
・ノートPCの潤沢なリソースを遊び用だけに使うのは意義に欠ける
・IntelNUCは開発機として利用する
・外付けHDDはIntelNUCに接続する

上記を達成するには、以下の役割分担となった

ノートPC：ティックフィード受信＆蓄積サーバ
IntelNUC：MySQLサーバ
外付けHDD：データ保管場所

この2週間、この体制を構築するために奔走していた。
この期間で学習したことは、足場はまだまだ脆いということだ。

データを受信し、転送し、貯めこむ。
ただそれだけのシステムなのに様々なことを考えないといけない。

それと痛感したのは、自分が発想したことは、
大抵すでに誰かが発想しており、失敗しているか、成功し遥か先に進んでいるということ。
ティックフィードのアーキテクチャは、ほぼ0から実装したけれど、Java部分に関してはJMSと呼ばれるもので、代替可能であるようだ。

結局下調べが甘いままに着手したため、引き返せず拘ってしまった。

[0回]

これ（SOHORAID SR2）

とこれ（HGST 0S03663）

で整いました。
これらを合成して、

こんな感じに。かっこいい・・・。

USB3.0＆RAID1で利用開始。
速度は・・・

おっせええぇぇ！
RAID1だから？？？
USB3.0ポートに設定したはずなんだが・・・。

ポートを変えて再チャレンジ

速度でたー！
まぁ、バックアップ用なので速度そこまで重要ではないけれども。

ポート1個死んでるかもしれん((+_+))

[0回]

現在ティックフィードを受信PCに直接取り込んだティックデータを保存している。
PC用のディスクはSSDであり、OSのインストール先も同ディスクである。
早く以下のようなバックアップフローを踏みたいと考えている。
（考えているうちに購入に至っている記事である・・・）

PC→USB3.0接続（外付けHDD（RAID1））→BD

将来的にはBDへ焼いて直近データのみを外付けHDDに貯めこみたい。

さてこれを実現するにあたって必要なものはRAID１を構成するストレージである。
候補は以下２つとなっている。

①ラトックシステム USB3.0 RAIDケース(2.5インチHDD/SSD2台用) RS-EC22-U3R
②6G eSATA/USB3.0 2ベイ RAID0/RAID1/JBODストレージケース SOHOTANK ST2-SB3-6G

①は、安価で、異常時のブート音やメール通知機能を持つ監視ソフトが付属している。ファンレスのため、SSDでの運用を検討すべきと考えている。2.5インチディスクのみ対応している。RAID0,1対応。若干ダサい（重要）。
②は、①より高価であり、異常時のブート音やメール通知などの監視ソフトは付属していない。ファンが付いておりHDDの運用も検討出来る。格好いい。

まとめるとこんな感じ

	異常時 ブート音	監視 ソフト	ファン	2.5インチ	3.5インチ	RAID	自動 リビルド
①	○	○	×	○	×	0,1	○
②	×	×	○	○	○	0,1	×

自動リビルド○が付いている①が最有力だが・・・。
ガシガシトランザクションが発行されても良いようなものを目指すと、
HDDがより検討しやすいファン付の②が有力候補である。

では、搭載するディスクはどう選ぶか。
わがままを言えば、信頼性の高いエンタープライズ向けディスクが理想。
しかし、SSDもHDDもエンタープライズ相当のものを探すとかなり高価。

コンシューマ向けで信頼性の高いものは何か。。。
以下ページですぐに分かった。
HDD約3万5000台を運用した実績からSeagate製品の圧倒的壊れっぷりが明らかに
今年の統計データである。
上記公表データによればHGST（日立）一強のようだ。
ただ、HGSTはすでにWD社に買収されたとのことだ。
しかしHGST a Wetern Degital Companyというロゴになり、ブランドとしては存続という形の模様。

HGSTで検討したいが、さらなる細かいブランドで構成されているようだ。
・Ultrastar
　24時間365日稼働を前提としたモデル
・MegaScale DC
　年間180TB程度の利用を前提としたモデル
・Travelstar
　携帯性に重きを置いたモデル
・CinemaStar
　ビデオ再生向けの静音モデル
・Endurastar
　環境変化、耐衝撃に重きを置いたモデル

UltrastarかMegaScaleDCだろうか。

より調査を進めると、パッケージ販売や組み込み販売をする前提で卸した企業向け製品の在庫は、PCパーツ専門店などに売却され、部品ごとに分解されたうえで販売されるようだ。
これをバルク品と呼ぶらしい。

HGSTのバルク品を探すと、AMAZONでもすぐに見つかった。
・HITACHI HDD HTC SATA3G 3.5"1TB/7200 32M HUA722010CLA330 並行輸入品 HUA722010CLA330
これは、上記ブランドのUltrastarの系列になる。

それ以外にもNAS用として、以下のものが新しく期待度は高い。
・HGST(エイチ・ジー・エス・ティー) Deskstar NAS パッケージ版 3.5inch 3TB 64MBキャッシュ 7200rpm 0S03663
キャッシュサイズ、回転数、容量、AFT対応済みと申し分ない。

ということで、本来なら
①＋HGST＊の組み合わせを採用したい。となるが、
デザイン性は日々のモチベーション維持に重要だと考えているので、
②＋HGST 0S03663×2
とした。

しかし、さらなるハイセンスなバージョンがあり、こちらを採用。
デンノー SOHORAID SR2 (eSATA/FireWire 800/USB3.0) SR2-WBS3
シナジーストアという通販サイトで購入。今回の購入で売り切れとなったようだ。
USB3.0、3.5インチ対応、ハイセンスなケースに液晶付、RAID0,1対応、ファン付ということで、
自動リビルドが残念ながら無いので、片側のHDDが死んだ際は、電源を落として復旧作業というが必要な冗長（？）構成となった。注文したばかりなので届くのが楽しみ。

参考情報
・Googleによると、ハードディスクは温度や使用頻度に関係なく故障する

[0回]

・偏自己相関の計算がやっと出来た。
　いろいろ本を読み漁って、結局「経済の時系列分析（著：山本拓）」に書いてあった逐次計算方式を実装して、Rと計算結果が合致することを確認。
　疲れたー。

[0回]

・メール通知機能
　通知機能におけるメール内容で統計データを盛り込みたく統計機能を充実させる方向で開発中。
　モチベが維持出来ていれば良いので、本末転倒となりながらもOKとする。

・統計機能
　自己相関まで完成したが、偏自己相関で予想どおり躓いている。
　Rの出力結果と合わないので困ってる。

[0回]

・OAUTH2.0＆GMAIL＆Java　をローカル環境で実装
　かなり大変だったけど、道筋は通るようになった。

　OAUTH2.0は、アプリケーションがユーザーデータを扱うにあたって、
利用するユーザーデータの範囲（スコープ）について申請を行い、
一度ユーザーの認証を受けたら、それ以降はユーザーの同意なしで利用継続する認証技術のようです。
　・Googleのデベロッパーコンソールよりメール送信用のプロジェクト新規作成
　・API>APIよりGmailのAPI使用許可
　・API>認証＞新しいクライアントID作成＞installedアプリケーション＞その他
　・Jsonキーファイルをダウンロード
　・Javaにて、
　　・GoogleAuthorizationCodeFlowを生成
　　・credential = new AuthorizationCodeInstalledApp(flow, new LocalServerReceiver()).authorize（userId）
　　　※userId=認証のクライアントID
　　・実行後、ブラウザが立ち上がりグーグルアカウントへ認証要求が来るのでOKする。
　　・以降credential.refreshTokenでトークン最新化し利用する。
　　・認証済みcredentialを利用し、Gmailインスタンスを生成。
　　　　　 Gmail service = new Gmail.Builder(transport, jsonFactory, credential)

[0回]

今週は一度もCPU使用率の高騰を迎えることなく、
メモリリークをも起こらず過ごせた。
ティック受信と取り込みまでの仕組みについては実装完了としたい。

6ブローカーで1.4Gb/1weekとなった。
1.4 * １年（48） = 67.2Gb
データ量は、そんなに焦る必要は無いかな。
ただ、ファイル単位のサイズは抑えていきたい。
通貨ごとのibdファイルに出来ているけど、パーティション別のファイルに分割したい。
MySQLのバージョンアップを行えば出来るとのことなので、この土日でやりたい。

次は監視体制を整えたい。
ティック受信間隔を取っていると数十秒の間隔が発生していることがある。
MT4クライアントとサーバの接続が途切れていたり、
そもそものネットワークが切断されていたりする可能性がある。

ティックの受信間隔を指標とした場合に上記の問題を無視できない。

・メール通知
　OAUTH 2.0のAuthorizaitionCodeをもらえるとことまで来たが、
　ローカルマシンからGmailへ利用することが出来ない。困った。

[0回]

・ブログのレイアウト変えました
　ブログのページレイアウトがごちゃごちゃしていたので
　シンプルなものに変更しました。
　タイトルは変えようか悩み中。


・メモリリークについて
　ソースコードの見直しを行い、定期コミットのタイミングで参照が残りそうな箇所を修正した。
　DLLには、JVM生成オプションにVisualVMのVisualGCから詳細なメモリ状況が分かるようJMXを追加。
　ヒープメモリは綺麗な直角三角形になった。
　しかし、Old領域に少しずつメモリが残留しているようでなんだろうとは考えている。週次の再起動で済むなら、これ以上の深追いはコストに見合っていないとも感じている。

[0回]

この頃毎日試運用状態で、帰宅するたびにCPU使用率が高騰していた

原因は、JVMのメモリ不足でCPUの性能が良すぎたのか狭い机で、

ものすごく手早く作業をしていたような状態だったようでcpu高騰という形で顕在化していた。



いまは、悲しいことにメモリリークが見られているため、

プロファイラーを用いたり、ソースコードを見直したりしている。



また上記の原因究明のなかで、MT4→DLL→JNI→RMI→DBの流れを可視化したが、

思った以上に俯瞰する効果が高かったので怠惰せず、立ち止まって可視化するプロセスは継続したい。

[0回]

■平均の計算方法
平均を計算する方法は、
①毎回指定時刻から過去へ遡って各値の合計を行い、平均期間で除算する。
②平均量をから期間外となり除外するもの、期間内となり追加するものを考慮して計算する。
２つの方法がある。

②の具体的イメージは以下のとおり、i　はデータの並び。真ん中の平均は５期間平均で、現時点がi=6となった瞬間の処理内容である。期間外となるi=0データを除外し、期間内となるi=6データを追加することで計算量の増大を防ぐ。



■実験内容
上記２つの方法において、
値の範囲：1～1000万
値の増加方法：1ずつ
平均期間の範囲：1から99（下記図の横軸）
平均値算出回数：(1～99)　× (1000万)
1から99の期間ごとに、1000万回シフトして平均計算した時間（ミリ秒）の遷移を調べた。

・赤字が逐次計算
・青字が平均量計算


凄まじい違いが出た。
時々青字（平均量計算）でブレているのは検証方法の問題ではなく、おそらくJavaの問題。
ある回数のメソッド実行が行われると、最適化が走りJavaバイトコードへのコンパイルが再度行われるとか。

計算回数および平均期間が増大するごとに、①の逐次計算は指数関数的に処理時間が伸びる。
②の平均量計算は、計算回数に対しては一定で、平均期間が増大すると線形に増加する。

[3回]

おそましておめでとうございます。

完全放置でトレード自体もなんの狙いもないトレードを１、２回した程度（しかもマイナス）です。
格闘ゲームばかりやっていました。

■ティックフィードシステムの開発
今年に入ってからは、FXについては少し距離を置いてましたが、置くなりにデータは貯めようという想いの元、ティックフィードシステムを作成しました。

ティックフィード自体はEA＋MYSQL用DLLという組み合わせで以前作っていて、一世代前のPCでは取込を行っていたのですが、これが完全にバカでした。
このMYSQL用DDLの作りが１ティック＝１コミットとなっており、それをSSDに対して行っていたので、SSDの劣化は恐ろしいスピードだったのでしょう。わずか一年でSSDが昇天しました。

この反省を生かし、次のような構成にしました。
EA＋ティックフィードDLL＋ティックフィード溜め込みJavaプロセス（RMI）＋MYSQL
なぜJAVAなのかといえば、Cで深く実装するスキルが全くなかったこと、仕事ではJavaがメインだったことが理由です。

EAは純粋にティック単位でDLLへティックデータを引数に関数呼出を行うのみ。※問題①
DLLでは、受け取ったティックデータに対して、システム時刻を生成して、それをJavaプロセスへ送信します。※問題②
Javaプロセスでは、受け取ったティックデータをインスタンス変数へ設定し、Listへ追加し溜め込みます。ティックデータが来たタイミングでコミット間隔時間以上経過していたら、その時点で溜め込まれているティックデータをすべてSSDへ永続化します。そのあとは、ティックデータをクリアし、再度ティックデータの受信を待ちます。

■問題
①Windows8でのMT4とDLLの稼働条件
かなり気づくのが遅かったのですが、terminal.exeにXP互換起動設定を行うだけでは足りませんでした。
EA→DLLの連携の際に、4023エラー（詳細不明）が発生してしまいフィードの継続ができなかったのです。
解決策は、簡単で「管理者権限で起動する」により起動することで解決しました。

②正確なシステム時刻
実は今も曖昧な部分ですが、その時刻に受信したのだからその値だとして進めるしかないという結論にいたりました。
調べてみても2000年以前の記事が多く、最近でもOS　WINDOWSの仕様による部分が占めていて、MS社に問い合わせを行うしかないです。
Cで取得しても、Javaで取得しても、ミリ秒以下の分解能を持っているとしか思えず、
仮に現実の時刻と多少ズレていたところで、なんの問題もないことが結論で出たので良しとしています（というより現実時間とPC時間がズレいて優位性を失ってしまう戦略は繊細過ぎて現実的ではない気がします。それでも挑むとしたらGPGPUやCUDA、コロケーションの利用など、技術的・金銭的にも高難度の問題をクリアしていく必要があります。これ以外にもたくさんの問題があるのでしょうが知る由もありません。）

■ティックフィード開発で得た知見
ティックデータを使ったトレードシステムを開発する上で、
ブローカー→PC間の通信時間は知っていて損はないと思います。
注文→ブローカー→約定
の間の時間を知ることで現実的なバックテストが実施できるからです。

■これからやること
・GUIの検証システムの充実
GUIを用いたグラフィカルな分析をガンガン出来るようにしていきたいと考えています。
既に、基本のシステム構成は製造済みで、検証観点に注力出来るような構成になっています。

・高校数学の復習
結局難しい本を読む上でここをおさえておかないとにっちもさっちも行かない。

・時系列解析、機械学習、その他統計の理解
オリジナルの考えも大切ですが、同じくらい先人たちの試みも重要です。この領域の勉強は難しくて、どういう前提が置かれた上で成り立っているのか分かっていないととんでもないことをしてしまう怖さがあります。

・考えを深める
仮説を立てることはしょっちゅうやっていましたが、子供の想像の域を脱しておらず、またそれに対する検証があまり無かったのが正直なところです。
前述したGUI検証ツールにより、随時仮説検証を行い、相場に対して明言出来ることを増やしていけば自ずと答えは出せるようになると考えています。

[2回]