coincheckの一覧取得APIではページネーションという仕様を使っています。しかしこのページネーションについてcoincheckの説明が不足している上に不具合があって大変カオスなことになっています。2017年12月にAPIの仕様変更があったので、この変更で不具合は直っていることを祈ります。今回はこの一覧取得APIから任意のIDのデータを取得する方法について書きます。
coincheckの一部APIではページネーションにてデータを分割して取得することが可能です。
・PARAMETERS
limit 1ページあたりの取得件数を指定できます。
order "desc", "asc" を指定できます。
starting_after IDを指定すると絞り込みの開始位置を設定できます。
ending_before IDを指定すると絞り込みの終了位置を設定できます。
coincheckのAPIでシステムトレードプログラムを作る際に必須の機能なのが発注と同時に損切りの発注を出す処理です。これFXの世界ではイフダン(if done)というらしいです。今回はこの処理の実装方法について書きます。
coincheckのAPIの実行順としては下記のようになります。
ポジション一覧APIを利用しなければならないというのが味噌です。これが分かるのに時間がかかりました。
株やFXはAPIが用意されていないのですが、仮想通貨取引所はどこもAPIを用意しています。coincheckも例外ではなくAPIを利用してBitcoinのレバレッジ取引ができます。つまりは自分でシステムトレードプログラムを作ることができるというわけですね。個人の口座残高や売買などはPrivate APIという認証が必要なAPIを使用する必要があります。今回はこの認証をC#で実装する方法について書き残します。
細かいことはcoincheckのAPI仕様についてのページに書いてあるので参照してください。
coincheck.com
簡単にいうと下記の3つの情報をHTTPsのヘッダに書き込めば良いみたいですね。
KEYはcoincheckにログインして作成することができます。権限も細かく設定できるので、必要最低限の権限だけ付与しましょう。特に送金は余程のことがない限り権限付与しないほうが良いです。NONCEは前回のAPIの実行時より大きい値であれば何でも良いです。そしてSIGNATURE、今回はこの作り方について書きます。
ユーザーに画像を選択してもらうアプリケーションを作成する場合、画像ファイルをローカルに保存することになると思います。このプレビュー画像をアプリケーションに表示しようとしたときに、このローカル画像を読み込まなければなりません。このときにImageクラスのFromFileメソッドを使用すると一見簡単なのですが、ファイルをロックしてしまうため気を付けてください。
例えば下記のようなコードが存在すると危険です。
var image = Image.FromFile(fileName);
これが実行されるとfileNameのファイルがロックされたままとなります。再び上記コードが呼ばれるとIOExceptionが発生してしまいます。MSDNにも「The file remains locked until the Image is disposed.」と記述されています。
JSONのHTTPSによるやり取りにJson Web Token(JWT)という規格があります。JSONに署名して中間者攻撃や悪意ある送信元からのAPI利用を防ぐことができます。しかし当然ながら.NET Frameworkにはそのようなライブラリは存在しません。Nugetにも該当するライブラリを見つけることができなかったので、自作してみました。
Json Web Tokenとは送信者がJSONに署名し、受信者が署名を確認して送信者と偽装のないことを確認するための規格です。略してJWTと呼ばれます。このJWTは以下の3つの要素からなる文字列として表現されます。
ヘッダーは下記のようになります。署名の暗号アルゴリズムとJWTであることを明記します。暗号アルゴリズムは色々あるようですが、今回はRS256という形式を使いました。これは公開鍵暗号方式でハッシュアルゴリズムにSHA256を使うという意味です。
{ "alg": "RS256", "typ": "JWT" }
署名はヘッダーとJSONをバイト文字に変換し、ピリオドを区切り文字として繋げます。これを暗号化したものが署名となります。3つの要素はピリオドで区切られており、また署名は送信者により暗号化されています。受信者は署名を復号化し、JSONと比較することで偽装ないことを確認します。ここで一致しなければ、偽装されているか、送信者が違うということになります。
WindowFormにはグラフ描画ライブラリが標準で用意されているのですが、WPFアプリケーションにはそのようなライブラリは用意されていません。今回はWindowsFormのチャートコントロールと、ググって見つけたSparrow Toolkitというチャートライブラリを使用してグラフ描画を行ってみました。
WPFではWindowsFormHostを使ってWPF内でWindows Formのチャートコントロールを使ってグラフ描画を実装することができます。
qiita.com
しかし、これには問題があります。WindowsFormは全てのWPFコントロールの上面に表示されてしまうのです。このため、リッチなUIをデザインしたとき、本来は別のコントロールの下面になって隠れるはずの場合でも、上面に表示されてしまいます。つまりデザインが崩れるのです。
d.hatena.ne.jp
WPFのListViewを使ってリッチなカスタムリストを作成したとき、クリックしたときに背景色が変わるのを解除したくなります。せっかく綺麗なデザインにしたのにクリックした瞬間に選択色がついて台無しに。しかし残念ながらListViewのプロパティ1つをFalseにすれば済むような話ではありませんでした。
こんなListViewがあったとします。ここで例えば「0005」をクリックしてみます。
WPFアプリケーション開発において多言語対応というのは悩みの種です。Androidはstrings.xmlでテキストは管理され、各国語のstrings.xmlを作成すればOSが使い分けてくれるのですが、WPFにもそんな便利機能はあるのでしょうか。
どうやらLocBamlツールというものを使う方法がMicrosoftの標準推奨だそうです。が、ググってみれば分かりますが誰も使っていません。MSDNを読んでみても数秒でコレジャナイ感でいっぱいになります。
方法 : アプリケーションをローカライズする
Android Databindingを使用してアプリ開発を行っているのですが、Fragmentを使った画面遷移でアプリクラッシュする問題に直面してしまいました。原因を特定するのに時間を使ってしまったので、記録として残しておきます。
この問題に直面して数日経過してしまったため詳細は記憶が曖昧になってきているのですが、問題はActivityのButtonが押下されたときにFragmentの表示を切り替える場面で発生したと記憶しています。1枚目のFragmentはActivity表示時に一緒に描画されていたのですが、それを2枚目に切り替えようとしたときにクラッシュした感じですかね。クラッシュした箇所はFragmentのonCreateViewの中のLayoutInflater.inflater.inflaterメソッドだったと思います。
public static class ExampleFragment extends Fragment { @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { // Inflate the layout for this fragment return inflater.inflate(R.layout.example_fragment, container, false); } }
はい。分かる人は分かると思うのですが、Android DevelopersのFragmentのリファレンスにも記述されている自動生成のコードです(フラグメント | Android Developers)。そして、記憶が曖昧ですが下記のようなエラーメッセージが出てました。
Duplicate ID, tag null, or parent id with another fragment for Fragment.
良く分からないですけど、LayoutInflater.inflater.inflaterメソッドの第一引数であるR.layout.example_fragmentが重複しているようなのです。そんなことってあるんですかね…。対策をググってみると重複しているなら削除してしまえという対処療法は見つかるものの、根本的な解決策は見つからぬまま。うーんどうしたものか。
WPFアプリケーションを実行した時に画面がレンダリングされる前にXamlParseExceptionがスローされてクラッシュすることがあります。この例外はデバッカーで原因位置を特定できない場合があり、初めて見たときは絶望と挫折を経験する人もいるかもしれません。僕もWPFアプリケーション開発初期に調べて時間かかった経験があるので、今までのノウハウをメモとして残しておきます。
WPFアプリケーションにおいてXAMLをロードしてパースするときやXAMLのAPIを使用中に何らかのエラーが発生したときにスローされる例外です。
XamlParseException クラス (System.Windows.Markup)
相変わらず奇妙な機械翻訳でMSDNの説明は分かりにくいですが、XamlParseExceptionという名前から先入観でXAMLに問題があると思ってしまいますが、上記のようにXAMLのAPIの使用中のエラーでもスローされるようで、必ずしもXAMLに問題があるわけではありません。というか、多くの場合はそうでないような…。
