FXのやり方（基本編）

相場の動き方についてまとめてみようと思う。

取引の仕方

　ランダムウォークと呼ばれる時系列にローソク足が並んでいるグラフを見て｛ロング・ショート｝売買を行い、差益で稼ぐのがFXである。

話は簡単で、ロング「安値で買い、高値で売る」、ショート「高値で売り、安値で買う」の２つの方法で利益を得ることができる。

じゃあ安値てどこ？高値てどこ？という部分に行き着く。

それは
　過去を見て、
　現在で判断し、
　未来を予測する。

これの意味を理解しないと負けるだけです。

ここまで理解ができたら次は、変動について説明。



変動パターンの種類

・上昇する
・変化なし
・下降する

単純に考えれば3パターン。

相場自体落ち着いてれば変化無しの比率が高まり、
上昇傾向なら下降より比率は上がり、
下降傾向なら上昇より比率は上がる。

この３つの状態によってバランスが保たれて
過去と現在が出来上がっている。

一方的になっていればそれは暴落という。
普段は均衡状態で少しの変化が加わり上昇・下落を繰り返している。

ちなみに過去から現在、現在から未来は延長線上にあるので
１つ先の未来を知るのに様々なテクニカル手法が考えられている。

それらは他のサイトは取引業者の説明を参照する事。


売買のタイミング

・時間帯
　主にボラティリティ｛変動幅｝が高い時に売買を行うのが短気取引で欠かせない。

例えば変動幅が狭い時に取引し多場合、目標の差益を得るのにとても時間がかかってしまう。
その間に経済は常に変化し続けているので、突然のアクシデントが起きて大幅は赤字を出してしまっても保険が無いので借金してでも返さないといけなくなる。
なので、なるべく売買が集中するボラティティの高い時を狙って売買すること。


・売買の方法
　前に述べたが２つの方法、ロング・ショートで売買を行う。
もう少しいうと、チャートを見ると、波のように上がったり下がったりするので

　・下がったタイミングでロング
　・上がったタイミングでショート

なのだが、必ずしも今現在が底だとしても折り返し地点なのか、折り返さず下がるのか分わからない。そういった相場の買い方で
　
　・順張り
　・逆張り

の2種類の考えがある。


・ローソクの見方
　ローソクには４つの情報がある。
　始値
　高値
　安値
　終値

　いろんな見方があるうちの１つとして以下の見方を参考にしてほしい。
　まず最初に注目すべき点は、

　高値・安値、ヒゲの部分
　始値、終値、四角の部分　

２つに分けて考える。
四角の部分はその時間帯の勢い。
ヒゲはどちらに売買が多くされたかの抵抗力。

体にゴムを括りつけて一方公に走るとある距離でゴムの勢いで押し戻される。

そんなイメージだと思ってくれればいいかもしれない。

ちなみに抵抗力というのは
　利食い
　ポジ

どちらかで動きが変わってくる。

利食いならまさに壁。指値の壁があって突破できれば後はガバガバ。
ポジなら壁がないのでスカスカ。

相場の均衡を保ちつつ、どちらかに値動きがするのでそこに注目しておくと良い。


・売買のタイミング
　これが分かればいろんな数式など不要で１つの計算式で求められれば全員がお金持ち。
でもそんな事にはなってないから、そういうものはまだ見つかってないのでしょう。
（見つけられる人には見つかっているのかな？）

　誰かが得すれば、誰かが損をする。

　大は小を兼ねる。

こういった法則があるので、非常に難しいのですが、

日足を見てみると必ずどちらかに変動して終値を付けています。
つまり何が言いたいかというと、

　朝にどちらかに買って、夕方売れば

勝ち・負けは5割の勝負になっているということです。
スキャルの場合は基本的に3割のジャンケン勝負じゃないでしょうか。

まあ買うタイミングはどこでもいいのですが、スキャルする場合は、トレンドを追いかけて
頂点ロング、底辺ショートを掴まないように戦略を立てて置くことがポイントだと思います。


例として
・ある一定のボラティティがある状況下で、激しく値幅が動いた瞬間が売買の開始タイミングで
・基本は順張り、かつトレンドが見える方向で購入。
・pips、もしくは時間で手仕舞いにする。

など、方針を立てて置くことが勝利の条件ですね。

もちろん敗北の条件も決めておかないとチャンスを逃すばかりか焦げ付く可能性もあるのごで注意を。

順張り・逆張りについて
　追記ですが、順張りと逆張りについて説明しておかなくてはならない事に気づきました。

ボラティティが高い相場で購入するタイミングはどちらかに一方的に買われた時になるのですが、

この時、
　上に上昇した時に上方面に買う事を順張り。
　上に上昇した時に下方面に買う事を逆張り。


これはすごく重要です。
順張りは勢いの伸びしろに期待して差益を取ろうとする作戦で、
逆張りは今がターニングポイント、そこから差益を取ろうとする作戦です。

相場の動きで判断して順張り、逆張りどちらにするかでプラスかマイナスかが決まるのでここがとても重要です。
ちなみに買うタイミングがどうのっていうのは含みません。
差益が出るのはボラティティが保証されてるので、ピンポイントの勝負ではなく、手段より目的、差益を取れる方向に注視しましょう。

MVCモデルを見直そう

最近では定番となったMVCモデル。

名前はネット上で沢山の記事があるので知っている方、使っている方は多い。
ASP.NETもMVCやMVVMという進化を経て現在でも発展している。

このMVCモデルを簡単に説明すると、プログラムをModel-View-Controlの３つのブロックに分けて作りましょうというオブジェクト思考、UMLなど言葉が生まれる前のプログラム言語smalltalkで生まれた構造化設計手法である。

では次にsmalltalkを知っている方、使ったことがある方はいるだろうか。

知らずに使うことは可能だけど、アーキテクトの理解を進めた先に見える何かがあるので今回はここをテーマです。

まずはsmalltalkについてはWikipedia参照してください。
https://ja.wikipedia.org/wiki/Smalltalk


smalltalkの中核ツールであるclass browser
http://www.bing.com/images/search?q=Class+Browser&FORM=HDRSC2

注目ポイントはsmalltalkの設計思想。

計算機を計算機の集合体として構築し、さらに計算機を構成する個々の計算機も計算機の集合体で構築するというように、再帰的な計算機を構築すること。

再帰的な計算機を構築している無数の計算機は、個々の内部には干渉せずメッセージによる通信のみによって相互作用を発生させ目的の計算を完遂させる。

計算機＝オブジェクトに置き直して読んでみると、

objectをobjectの集合体として構築し、さらにobjectを構成する個々のobjectもobjectの集合体で構築するというように、再帰的なobjectを構築すること。

再帰的なobjectを構築している無数のobjectは、個々の内部には干渉せずメッセージによる通信のみによって相互作用を発生させ目的の計算を完遂させる。

オブジェクトといっても解釈が沢山あるので以前書いた、オブジェクト指向の間違いを正す　の通り、実データの集合体、という理解で進めてほしい。
オブジェクトはクラスで表す事ができるので、先ほどの文章のobjectをclassに置き換えるとsmalltalkとはどういう構造しているのかが分かる。つまりこれがMVCフレームワークの元祖、オリジナルである。

はたして、いろんなフレームワークでsmalltalkで設計されたMVCフレームワークが実装されているかどうか。別に進化をとげる事は良いが、オリジナルを知ることでフレームワークの良くなった・悪くなったかどうかが判断できるようになる。

ざっとまとめると、
classをコンポジットパターンで構築し、さらにそのクラスもコンポジットパターンで構築される。
これを再帰的であると表現する。
このような構造にしておくことで無数のclassが存在していても個々は独立したclassになるので互いに干渉しない。
中身を知らなくてもコンポジットパターンの頂点に立つclassを扱う事で内部には干渉せず相互作用を発生させ目的の動作を完遂させれる。


ネット上ではいろんな人が聖書のようにいろんな解釈で説明、またはフレームワークとして実装されている中、何がオリジナルであるかを知ることで派生のMVCがどうであるかの判断もつくようになり、MVCはの本質について理解は深まったでしょうか。

クラウドは安全か？

答え：安全でない。

大手ならデータセンターに保管されているから安心、というのはデータが紛失しない保証であって、データの改竄や第3者による閲覧についてはセキュリティの問題であるから。

しかもDropBox、OneDrive、GoogleDriveなど誰でも使える無料サービスならもっと危険。

その理由はアカウント・パスワードが流出すればだれでも覗きができる環境可能になっているからである。

安全な使い方は、

・どうでもいいデータを置き場にする
　→テロリストによってデータセンターが破壊されてデータが消えても困りませんね。

・暗号化、パスワード付ZIPにした重要データのバックアップ保管場所として利用する
　→急にサービス終了してもバックアップの保管庫なら安心。


個人的に危惧しているのは大手クラウドサービスで格納しているデータすべてがプライベートはビッグデータとして扱われることです。
今まで個人のパソコンにあったデータがクラウドと呼ばれるストレージサーバーに集約され、普通では手に入らない貴重なデータがユーザー自ら格納してくれるわけです。
無料サービスの対価はそういったところにあるんじゃないかなと思っています。

正しいIT化の自動化（プログラムレス）

２０１２年あたりに超がついた高速で開発できますっていうのがあることを最近になって知った。 その時期に集中的に特集が組まれているのでネット上によくある商用の広告・特集記事なんだろうけど、何か得るものがあると思い読んでみた。 第一印象は、 「へーこんなのあるんだ。でもそれってロボットがロボットを作るようなものだよな。」 例えるとオペアンプ自体がプログラムレスの仕組で、出力を入力へフィードバックすることで増幅するものが 自動化に欠かせない要素になる。 　「このソリューションを使って自分自身は作れるの？」 って思ったので調べてみたら、「作れません。」ということが分かった。 これは成果物を出力したらそれっきり。 成果物を作る過程にできた部品を再利用は可能。 その部品というのは、画面レイアウトであったり、フローチャートであったり、DBテーブルである。 プログラム作っている人なら分かると思うけど、これらって仕様で定義する部分なので 再利用できるの？っていうのが疑問点だろう。 仕様をGUIで書けば物ができる、というのはいいアイデア。 なんたって仕様バグがそこで分かるんだから。 ただ、こういう雇用を産まないビジネスモデルだとこのシステムを支え合える人がいないから 売り切りの１点ものだと思って良いでしょうな。 デザパタで言い表すと、 ファクトリーパターンに設計図を渡すと作ってくれる。 そんなようなツールが高値で売買されているのを見ると、これは情シス部門を持たない経営者向けで コミュニティーはベンダーで囲ったクローズドな販売網なんだなっていうのが伺える。

object-Json相互変換

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Json;
using System.IO;

namespace ConsoleApplication12
{
 class Program
 {
  static void Main(string[] args)
  {
   var model1 = new testData() { X = 123, Y = 345, P = new test2Data() { Z = 999 } };
   var json = JsonHelper.ToJson(model1);
   var model2 = JsonHelper.ToObject(json);
  }

 }

 public static class JsonHelper
 {
  public static T ToObject(string jsonString)
  {
   var jsonBytes = Encoding.Unicode.GetBytes(jsonString);
   using (var sr = new MemoryStream(jsonBytes))
   {
    var serializer = new DataContractJsonSerializer(typeof(T));
    return (T)serializer.ReadObject(sr);
   }
  }

  public static string ToJson(object obj)
  {
   using (var ms = new MemoryStream())
   {
    var s = new DataContractJsonSerializer(obj.GetType());
    s.WriteObject(ms, obj);
    return Encoding.UTF8.GetString(ms.ToArray());
   }
  }
 }

 [DataContract]
 public class testData
 {
  [DataMember]
  public int X { get; set; }
  [DataMember]
  public int Y { get; set; }
  [DataMember]
  public test2Data P { get; set; }
 }

 [DataContract]
 public class test2Data
 {
  [DataMember]
  public int Z { get; set; }
 }
}

オブジェクト指向の間違いを正す

オブジェクト指向がしっくりこないと思ってたいたのがようやく構造設計でオブジェクト指向を設計したらようやく答えが見えたので書き留めておこうと思う。

私はIT業界に就業して、まず初めに構造設計から入り、1ソース数万行のソースコードに仕様追加などを経て、今まで対岸の存在であったオブジェクト指向だったはずが

「オブジェクト指向はいいよ」って布教活動する人が周りに増えてしまい、しぶしぶオブジェクト指向の世界に入信している。

しかしオブジェクト指向の世界はどうも無駄が多く、同じ名前の関数を複数のクラスにまたがって呼び合ったりする構造、ネストが深くなり逆に分かりにくいんじゃないの？ってさえ思った。

色んな本やネット、同僚からの話を聞いてもしっくりこない。

大規模なソースコードこそ悪とされる風習の中で１ソース数万行とかざらだった現場上がりの人間からすると、Grepだけで問題の個所に辿りつけたのに今じゃ小さなオブジェクトが無数にあって綱渡りして進まないと答えにたどり着けない。

その話をすると何を言ってるんだ、オブジェクト同士は互いに協調しあって動いているから回りに影響を与えない為にそうなっている。と説教されたとしても自分のイメージ空間には

「宇宙空間に漂う惑星が互いに協調しあっているんだ！」

と、目に見えないがそこにはあると言われても、オカルト的な宗教の勧誘を受けている感覚に襲われる。

自分の中にあるオブジェクト指向に対するモヤモヤとした感情はずっと片付かないものであったが、ようやく構造設計で学んだ知識を基にオブジェクト指向の概念を自分で構築してみてようやく答えが見つかったのだ。

何がしっくり来なかったのか説明する前に、まず生みの親も現在のオブジェクト指向は良いように見ていないのでそこから読みほどきたいと思う。

-------------------------------------------------------------

Wikipediaより

Eclipseを開発したDave Thomasや、オブジェクト指向という言葉の生みの親であるAlan Kay博士は、オブジェクト指向という言葉は失敗だったと語っている。

本来オブジェクト指向が重視すべきは「オブジェクト」ではなく「メッセージング」であるにもかかわらず「メッセージング」がおろそかにされているためである。特に言語の進歩において「オブジェクト」や「クラス」の側面ばかり強調される傾向にあり、Alan Kay博士は「Smalltalkが最高に好きという訳ではないが、他の言語に比べればマシである。」と述べている。

1つ目「オブジェクト指向という言葉は失敗」

　これはネット上や書籍の文献を読んでもわかる通り、漠然とした内容かつニュアンスがまちまち変わる。それはオブジェクト指向の多態性とも言える皮肉な事が挙げられると思っている。

つまり、

　アーキテクチャが正しく世に広まらなかったので、オブジェクト指向という言葉が失敗だった、と言える。

2つ目「重視すべきは「オブジェクト」ではなく「メッセージング」」

　1つ目の言い分だろう。

　オブジェクト指向とは、から始まると必ず「カプセル化」、「多態性」、「再利用性」などがずらっと出てくる。この言葉を指すものが「クラス図」「オブジェクト図」となってしまう。誰がこれらをメリットだと言い放ったんだが知らないけど、きっとUMLの売り込み文句とオブジェクト指向を抱き合わせて普及させたからだと思う。

3つ目「特に言語の進歩において「オブジェクト」や「クラス」の側面ばかり強調される傾向」

　多重継承、インターフェイス、MixInなどなど、その辺りの事を指していて「理想のオブジェクト指向」とは別の進化を広がっているを受け取れる。

4つ目「Smalltalkが最高に好きという訳ではないが、他の言語に比べればマシである。」

　これを語るにはSmalltalkを学ばないと分からない。

ざっくり見てみると、

　オブジェクトビュアーなるものがあって、そこでオブジェクトを構築するそうだ。

　つまりオブジェクトがメイン。クラスは存在しない？

-------------------------------------------------------------

オブジェクト指向と向き合って、書籍を読んでからこれがオブジェクト指向だと学びしっくりこなくて

理解しようと色々やってみてようやく分かった事がある。

それはオブジェクト指向の書籍やネットを見るモデリング手法で描かれる

　オブジェクト図、クラス図の考えがごっちゃになっている。

よくある例は、汎化の説明で

　「飛行機」←｛「ジェット機」「オスプレイ」「グライダー」｝

をクラス図で表現しているが間違い。

この図はオブジェクト図で表現すべき項目である。

プログラム化すると

　インターフェイスを定義してインターフェイスを持つ実体クラスを定義する。

これは正しい。オブジェクト指向において基本的なやり方である。

が、違う点は１つある。

これはクラス図で表現するのではなく、オブジェクト図で表現すべき事象であるからだ。

　オブジェクトの表現はクラス図ではなく、オブジェクト図。

クラス図は

　「パソコン」←コンポジット―｛CPU、メモリ、HDD、ヒートシンク｝

といったように、

　クラスは箱であり、その中にオブジェクトを入れる。

ここでピンと理解できた人は意識の高い人だ。

分からなかったら基本的な事が基本的すぎて目の前にあるのに気付かない、そんな状態だろう。

・オブジェクトはオブジェクト（実体）

・クラスはクラス（箱）

というように意味が全く違う。

実体を表す為、プログラムの制約上

　クラス（設計図）　→　インスタンス生成　→　オブジェクト（実体）

この流儀に沿ってプログラム化しないといけないので

オブジェクトを作るのみクラスを書く。これを利便性よくモデルクラスと呼ぶ。

モデルクラスには表現したいオブジェクトの要素を書き表す作業となるはずだ。

ここには振る舞いは存在しない、オブジェクトは置物みたいなものだから。

もしあなたが１００円ショップに買物に来てフライパンを買ったとしよう。

そのフライパンは通常のフライパンとして扱う人もいれば、DIYで別の部品として使う人もいるだろう。

オブジェクトとはそんなものだ。

そのように理解してもらえれば振る舞いなんて後から使う人が決めればいいじゃんってなり、オブジェクト自体に振る舞いはいらない。

ここでプログラム要素を交えてまとめると、

モデルクラスのインスタンスから特定の振る舞いを行う（コントローラクラスの）オブジェクトを生成する。

これに尽きる。

最初に決めるのはモデルクラスであって振る舞いは後付でも構わない。

こうする事で

クラス図には動きのあるオブジェクトをどう組み合わせていくか

という視点で図が描かれていく。

もちろんオブジェクトを表現するモデルクラスも出てくる。

出てくるものは汎化した最上位クラスが登場する。インターフェイスではない。

文頭で書いたようにクラス図もオブジェクト図もごっちゃになってクラス設計をすると

出来上がるソフトもごっちゃになって、無用なネストが多発しやすくなる。

さらに新しいモデルを作る時に回りに与える影響が大きくなってしまう。

つまり、本当に理解した人以外はオブジェクト指向を語ると混乱の元になって

汎化・特化・集約などを意識してやってみたがどうもうまくいかない。

なぜなら似たオブジェクトなのに別クラスで定義されているからなんて事が発生する。

こういう事が言いたかった。

長くなったので、今回はクラス図とオブジェクト図についての説明で終えようと思う。