こちらへ引っ越します。

[0回]

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

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

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

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


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


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

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

[1回]

StopLevelとは

業者によって、StopLevelなるものが設定されていることがある。
StopLevelとは、StopLoss価格を設定するときに参照される制約である。

　現在の決済レート±StopLevel値幅　∋　StopLoss価格

　※∋　は以内を意図する
　
現在の決済レートとは
　買いポジションなら決済レートはBIDとなり、
　売りポジションなら決済レートはASKとなる。
　ポイントは、約定価格ではない、という点。
　
StopLevel値幅とは
　例えばUSDJPYならば、MarketInfo("USDJPY", MODE_STOPLEVEL)で取得された値である。単位はMarketInfo("USDJPY", MODE_POINT)で得られる。
　なお、StopLevelは、各通貨ごとに設定されている。

StopLoss価格とは
　そのままの意味で、損切り注文の価格である。

補足というかコメント

　StopLoss価格は、一般的には損失幅を確定するために約定価格から計算されると思われる。
　しかし、MT4のStopLevelにおける制約は、あくまで現在の決済レートを基準に適用される。
　このため、約定価格から損失幅を差し引いて得られたStopLoss価格（約定価格－StopLoss幅）とStopLevelの制約範囲（決済レート±StopLevel値幅）は、整合しない。
　
　OrderSendの時点で、StopLossも合わせて設定するのであれば、あまり問題は無いのだろうが、ブローカーごとに処理を分けるよりは、毎回OrderSend、OrderModifyで解決を図ろうとしたところ、この問題に遭遇した。

[0回]

やったこと
■ＦＸ
・OANDA, DUKASCOPYティックフィード精緻化
・OANDA, DUKASCOPYの裁定機会調査
　有ったけど、ここに書いているって時点でお察し。

■仮想通貨
・BitFlyer CoinCheck裁定取引システム
　勉強と実益を兼ねてやったが、うまくいくまえに「やられ」ましたため、お蔵入り。

・BitFlyer 現物 ＦＸの価格差縮小を狙ったシステム
　BitFlyerにSFDなる価格差縮小プログラムが導入された結果、いろいろおかしな状況（縮小どころか、SFDの仕様不備を突いた取引が増えるとか）になっており、運用見合わせ。たぶんお蔵入り。

・BitFlyer FX 板を見る片張りシステム
　粗削り過ぎて運用見合わせ。たぶんお蔵入り。

・ICO1件投入中
　これが2倍程度まで増えたらいったん仮想通貨業界からはログアウトするつもり。
　このICOは直球ど真ん中みたいなやつなんで、丸ごと消えたりはしないと思われるが・・・。

やられたこと
■CoinCheckされた
　資金の3分の2が持っていかれている状態。
　仮想通貨の勉強を生かしきれずにこの結果を迎えた点は恥ずかしいとしか言いようがない。
　一応、返還はされるとのことだが、運が良かっただけ。全額ロストはふつうにありえた。

　CoinCheckやBitFlyer等のAPIは一通り触って、Webサイトも一通り触ったが、金融系のバックボーンを持つ人たちが入っている会社というよりは、Web系のバックボーンを持った人たちが入っていることは、当初から容易に想像できた。そもそも、API公開ということ自体、金融サービスとしては先進的。

　仮に金融系のバックボーンが入っているとなれば、信託保全を謳っているはずであるし（去年調べた時はどこもやってなかったのは把握していた）、この仮想通貨のボラティリティに対してあのレバレッジ（5～15倍）は用意しなかっただろう。

　あと、サーバ弱すぎというか、ＡＰＩ叩かせすぎというか、サーバダウンとかＦＸとは比べ物にならないくらい無責任にあり、金融系というよりかは仮想金融系といった印象。しかもZaifというブローカーに至っては、異常過ぎる異常値をつけて、刈り取ってくるし、GMOは安定のGMOクオリティで（知ってた）あったし、そこにクラッカーも乗り込んできたり、果てにはインサイダー横行と、考えるうる限りの劣悪な弱肉強食のサバンナ。いや魑魅魍魎蔓延る地獄か。

　一連の仮想通貨界は、ちょっと自分には毒が強すぎたかな・・・。
　税金も高いし。

今後の予定
■ＦＸシステム開発再着手
　正直、ＦＸ勝てるんかいな・・・って自信喪失している面があって、今回久しぶりに自分のブックマークを訪問しまくってみたり、界隈で儲かっているシステムとか探してみた。
　商材屋ですら、1年フォワードで勝っているし、純粋なシストレさんも鬼勝ちしている人を何人か把握出来て、未来は明るいなと感じた。それが自分にも当たり前のように置き換えられるとは思わないが、前向きな気持ちにはさせてくれる。まぁ、ブックマークのほとんどは、2013年あたりから消息を絶っていたが・・・

　リハビリ兼ねて何個かEA作ってみたい。

[1回]

シストレ

データフィード
■楽天証券MT4
　データフィード実施中。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

■OANDA JAPAN　　
　データフィード実施中。
　通貨数が豊富なので継続中。

■DUKASCOPY　
　データフィード未実施。　
　シストレやるなら透明性が最も高いと感じられる。
　NDD+ECNでDUKASCOPY BANKがカバーに入っている。
　シストレライブ取引は、国内からここ一択もありうるんじゃないか。

　APIも公開しており、通常のAPIとFIX APIがあるようだ。
　FIX APIも使ってみたいが、カストレーダーのため、必要口座資金（１００万）が満たせない。

　先日口座開設したばかりで、APIを読み解き中。
　公式は英語でかつJavaDocにほとんど記載がないのでなかなか読み解きづらい。

　補助的なサービスも充実している。
　例えば、通貨インデックスやセンチメント指数などマーケット情報として提供している。
　
　為替歩み値のダウンロードサービスも非常に強力。なんとティック単位からサポートしているうえに、ローソク足の集約期間を動的に指定したうえでダウンロードできる（！）。すごすぎ。

　あとネットで書かれているような不満は割と取り込まれているので、よく需要に応えていると思う（たとえばJavaのトレーディングロジックはデコンパイルが容易という懸念を書いたブログがあったか、現在は難読化をしてからコンパイルするオプションが導入されている。）

　たぶん、需要が期待できる機能を要望すれば応えてくれる気がする。

■最近やったこと
　・市場がクローズしたタイミングでのティックDB登録
　　ティックのDB登録タイミングが溜まった件数に依存していたため、実は土曜日のクローズ時間帯のティックが記録できていない問題があった。
　　サマータイム、取引時間を考慮した市場クローズタイミングの判断を実装し稼働させている。
　・LINE APIによる定期通知
　　毎日、ティックフィードサーバからLINE API経由で自身のアカウントに定期通知を行える機構を用意した。
　　
　・BitCoin フィードの開発
　　CoinCheckAPIを通して、データフィードを取る機構を開発。
　　1分データで取っている。

■データフィード全体の課題
　・BitCoinフィードの24365化
　　仮想通貨は24時間365日取引があるため、そのデータを漏れなく記録するのは個人では厳しい。
　　＃というか、そもそもデータフィードが必要なのか勉強不足で怪しいｗ
　　＃価格の記録を追えるならデータフィード自体、無意味ｗ

　・ネットワーク断線監視
　　自宅のネットワーク自体が問題がないかは記録していく機構がないと誤った学習を誘発する懸念がある。

　・ストレージ
　　RAID1のHDDに記録しているが、今のご時世、クラウドに保管するのがふつうか。
　　これは取引戦略が確立出来てからの話か。

シストレ
　敷居が高すぎる。
　もうどうやらディープラーニングが良いらしいとかそのレベルの情報弱者。

裁量
　今年は年初から10万を元手に裁量トレードをしている。
　中長期のトレードのみを手掛けており、一応2倍強には増やせている。

　さんざんやられてきた裁量トレードだが、ここ数年で一番伸びた自分の能力を振り返ると、決断力に他ならないと常々思っていたため、数年ぶりに再開した。

　トレード手法といったたいそうなものはなく、総合的に月足、週足、日足で鉄板トレンドとなりそうなところで入って抜くだけ。利益確定のタイミングがカスなので今後の課題。
　やばいと思ったら速攻逃げることは出来るようになったので、そこは成長したと思える。
　10か月、生き残ったのは初めて(^o^)

　みんなのFXで何となくやっていたが、USDCHFのスプレッドがデカすぎるので業者変え。
　これまた何となく先日口座開設したDUKASCOPYへ移動。
　正直中長期トレードだから、どこでもいい。
　みんなのFXのUSDCHFスプ5はない。

仮想通貨
　基本的には長期投資を想定している。6月頃から段階的に40万ほど入れている。あんまり増えていないが。
　こちらは最終的に200万程度は投入出来たらと考えている。余裕があればどんどん入れたい。最終的には1000万～2000万くらいになれば御の字だと思う。税制が追い付いておらず、雑所得の扱いということらしい（グーグル検索「仮想通貨　雑所得」）のでそこは受け入れるしかない。
　取引高は外国為替市場に比べれば圧倒的に少ない（2017年9月分は約7000万BTC、9月中の1BTC平均を60万として=1,4兆円くらいで、為替市場は一日あたり650兆円程度（上田ハーロー「主要国の市場規模」から試算））ため、仮想通貨次第ではあるが、まだまだ資金流入は期待出来る。
　資金流入というよりは、プラットフォームの変遷というか、時代の要求が強まればの話か。

　持たざるものが持てるものになる稀有なチャンスだと思う。

[0回]

ティックフィードの再構築中。
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回]

0円。
特にトレードはしていません。

今後2,3年は仕事の勉強や相場の勉強があるので無理でしょう。相場の勉強といってもパン・ローリングはもう読まなくていいですね。

仮に今後勝てても負けても誇大に喚き散らすような真似はしないつもりです。いい大人ですからね。

[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回]

・メモリリーク
　放置しようかと思っていたが納得感が無かったのでさらに調査。
　一手打ってみたが様子見。

・メール通知機能
　日々のモチベ維持のために、メールで簡単な統計情報を送るようにしたい。
　GmailのSMTPでメール送信を試みたところ、
　セキュリティレベルの低いアクセスだけど良いの？と。
　OKを押してもよかったが何となく時代の潮流に乗れていない気がして調べた。
　
　OAUTH 2.0という認証機構を利用すればいいらしい。
　ローカル環境からこれを利用する方法を探していたらドハマり。
　折れそうである。

[0回]

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


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

[0回]

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

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

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



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

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



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

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

[0回]

OS:Windows8.1

①
RAMディスク化ソフトを
http://buffalo.jp/download/driver/memory/ramdisk.html
からダウンロード

②
インストール

③
再起動

④
RAMディスクを「Z」ドライブとして生成

⑤
再起動

⑥
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" -disk-cache-dir="Z:\Chrome\Cache"

な感じで指定

⑦
タスクマネージャよりGoogle Chromeのものをすべて停止。

or 

再起動

⑧
キャッシュフォルダに（ガンガン）ファイルが作られていることを確認して終了。

5分でもう７MBとか書き込んでいることに恐怖。
もう２年くらい使ってしまった状況であるから早めに本体のディスクドライブに依存しない環境構築を急がなければ・・・。

[0回]