コンピュータ用語
フェールオーバー
片方が壊れたら自動でもう一方に切り替える。障害で動かなくなったとき用に予備で動かしていてるシステムについて、主となるシステムがが壊れた時に自動的に予備に切り替える方法。
ホットスタンバイ
デュプレックスシステム（二つ動いているシステム）における予備の待機状態の一つ。
いつでも仕事が始められるように準備が整った状態で待機しておく。→完ぺきに準備が整っている状態
すぐ切り替えれられるメリットがあるが常に動かす為コストがかかる
サーバダウン
処理能力の限界で力尽きる
ラッピングAPI
それぞれのAPIを利用しているシステムはそれぞれのAPIに対してデータを取得するのに毎回そのデータのルールに基づいた取り出し方をしなければいけない
携帯というシステムがあったとして
写真 メールの文章 電話番号
photo［1,2,3］mail［1,2,3］ number［1,2,3］
携帯からデータを持ってくるには命令としてそれぞれ
select photo api1,2
select mail api1,2
select number api1,2
みたいにしなきゃいけなくて
太字の部分を指定して接続しなければいけないのを、keitai APIでラッピングすることによって
keitai api 1,2みたいにすれば相手を意識せずにそれぞれがデータのやり取りができるようになるイメージ。
APIはプログラムが何かのシステムに接続する時に窓口として置いておかなくてはいけないので、それを統一する動きがラッピングです。
冗長化構成
予備を置いておく構成
シングル構成
サーバ一つ
仮想環境
一つの物理サーバに仮想的にサーバを置く
クラウドの状況に仮想的にサーバを置く
ストリームデータ
前回記事にしたストリームコンピューティングの中でストリームデータの処理ってのがありまして、これなんだと。
ストリームデータというのは連続して送られてくるデータのことをいうみたいです。
株式市場とかってずっと動いてますよね。工場についてるセンサーとかもずっと動き続けてます。
これって連続してずっと送られてくるし、しかも構造化されてないものが多いみたいです。
構造化出来そうなデータって表とかDBにできるデータなんですけど、センサーとか株式市場の常に動いてるビッグデータとかって構造化出来なくて非構造化のデータになります。
で、ストリームコンピューティングの技術だとこういう非構造化で連続してポンポンくるデータを処理できるみたいです。
以上です
株式の注文方法2
逆指値注文
価格が上昇し、指定した値段以上になれば買い
価格が下落し、指定した値段以下になれば売り
のようにあらかじめトリガーを設定しておき、トリガーの価格になれば注文
メリット
ストップロスプロフィットホールド
保有する銘柄あるいは信用建玉（取引約定後反対売買されないまま残っている未決済株）を株価の下落局面で損切りするときに利用
今すぐ売りたいわけではないが、株価が急落したときに損を最小限に抑える
買い注文では、株価の上昇局面で買い時を逃さないようにする
長期間動きが見れない人、昼間見れない人
デメリット
価格優先に加えて時間優先の為約定せず、その後指定した指値にならないときがある
逆指値の成行注文にするとそれ以下の価格になった時の最高値で約定する
リスクとしては成行注文と同じ
メリットもそう
トレールストップ注文
高値400円で買った銘柄に高値−40円でトレールストップ注文
万一下落して360円になれば売り発注
上昇が続けば継続
上昇後に下落すれば高値−40円で売り発注のように自動修正
追う（トレール）ようにして、価格になれば止める（ストップ）
※トレンド相場
上昇か下落かいずれかの方向に値動きが続く相場
注文時の価格と約定された価格の差
株価アラート
お客様があらかじめ登録した銘柄のお知らせ株価をコンピュータが自動的に監視
その価格以上か以下になればお知らせメールを送る
ある日の株式市場で最初に売買が成立した株価
その日の株式市場で最後に売買が成立した株価
株価は買いたい人と売りたい人のバランスによって決まる
投資者1 10万の買い注文
投資者2 10万の売り注文
成立
この取引がその日の朝イチで行われればそれが始め値
1日の最後だったら終値
前日の終値が9万円で翌日の始値が10万円だったらその間に会社にとって価値の上がるニュースやイベントが起きてる
反対であれば逆のパターン
高値
ある一定の期間で最も高い値段
安値
ある一定の期間で最も安い値段
以上です
色々2
インターネットでやり取りする情報を暗号化して送受信する為の仕組み
インターネットの線の中を通る間は情報を盗まれたり盗み見られたりする恐れがある為、見られても実害がなくなるようにするために、通信内容を暗号化する、っていう感じです。
内容としては、
クライアントがまずサーバにコンタクトを取る
サーバはこれを使って暗号化してほしいという公開鍵が入った電子証明書を送る
クライアントはやりとりしているサーバが本物か確認する
本名だった場合は公開鍵を取り出す
クライアントが秘密情報をやり取りするための共通鍵をつくる
共通鍵を公開鍵のルールに従って暗号化する
暗号化された共通鍵をサーバに送る
サーバは暗号化された共通鍵を秘密鍵を使って元に戻す（複合）
あとはそのルールに従ってやりとりする
以上です
