torum

主に開発中のアプリにまつわる技術系の事。

東証APIサービスが使い物にならない件について

10年以上ずっと待ち望んでいた、東証API公開・・・株式市場のマーケットデータが(証券会社や機関投資家以外にも)WebAPIで公開されるというニュースが飛び込んできました。

www.jpx.co.jp

 

ずっと待ち望んでいただけに、このニュースに(一瞬)声を出して喜んだのですが、そんな自分が愚かでした。公開されたAPIインターフェイス仕様書をざっと見てガックリしたのは私だけではないでしょう。

「約定値段情報API」の仕様書は非常にざっくりとしたものですが、簡単に言うと、

https://api.arrowfront.jp/stockprice

というAPIエンドポイントに、HTTPのPOSTでRequest Bodyに入れたJson形式で銘柄コードとAPIキーを送信し、そのリクエストのReponse BodyでStatusCodeや銘柄の約定価格データが返却される仕様になっています。

頭を抱えたくなります。RESTでもなければ、かといってRPCでもない

 

ja.wikipedia.org

 

単に取得するだけなのだから、HTTPのGETでAPIキーはヘッダに、銘柄コードはURIのパラメータでやろうな、と。Jsonのレスポンス(出来たらXML形式も用意してくださいね)にHTTPもどきの「StatusCode 200」とか埋め込んで返却とか、HTTPのステータスコードの仕様メカニズムを完全に無視しているのはどういう事?独自エラーコードなら定義は?とか、それどうなのよ?と思わせるような点というか、色々と突っ込みどころが多すぎで・・・

しかも、

本サービスは、20分ディレイの約定値段情報(更新間隔:1分毎)を提供します。

こんなん使う人いるのだろうか。

その上、約定値段情報の利用だけで、基本料金が8万円とか。第三者提供はさらに課金って、アプリ作って公開したら第三者提供になってしまうのだろうか・・・

因みに、暗号資産の業界では・・・

既に暗号資産(いわゆる仮想通貨)の取引はREST(ful) APIで全て出来ています。「最新取引価格(LTP)」といったマーケットデータだけでなく、取引を含む各種操作ができます。APIによっては送金なども可能。さらにWeb Socket Streamsなどのリアルタイム通信にも対応している所もありますね。

当然、利用は完全に無料ですので、様々なデベロッパーが利用してエコシステムが出来つつあります。

一例として、ビットバンクという日本の取引所は以下のようなAPIを提供しています。

github.com

他にも、ビットフライヤーAPIドキュメントはこちら。 海外(英語圏)は本家という感じでもっと色々あります。

ビットコインやその他の暗号資産に関わる取引におけるAPIは、ぶっちゃけ、今回の東証APIよりも、何倍も良く設計されており、機能も多く、それらの利用は当然のように無料です。

個人がビットバンクのAPIを利用して、楽天証券が出している株式トレーディングツール、「マーケットスピード」のようなデスクトップの取引アプリを開発するのも簡単です。

例えば、こんな感じの。

f:id:torum:20210123040858p:plain

 

あ、はい、これ自分が使いたかったので自分で作りました。

 

github.com

 

 こんなのも作れます。

f:id:torum:20210123041729p:plain

取引データのライブチャート

github.com

 

因みに、上記のはマイクロソフトのアプリストアで(当然無料)公開していますので、誰でも気軽に使えます。

www.microsoft.com

 

東証APIは酷すぎて、何も作る気が起きません・・・

 

MPD (Music Player Daemon) のススメ

MPD (Music Player Daemon) とは何か、って話しなんですが一言で言うと、音楽再生するミュージックプレーヤーです。MPDが他と何が違うかというと、それ単体では何もしないで、サーバーとして機能します。

つまり、他のクライアントから操作する事が出来る、という事です。いやゆるメディア・サーバーの一種です。具体的にはリビングのパソコンに入れたMPDを携帯のアプリやノートパソコンからコントロールする事が出来る・・・ソファに寝転んだままで、ってやつです。

それiTunesでもリモートってアプリで出来るじゃん、という声が聞こえてきそうですが、MPDはもっと本格的で、プレイリストの編集や検索などフルコントロールができます。他にもストリーミングとか諸々。しかもWindowsMacだけでなく、Linuxでも動きます。

自分の場合は、貯めこんだ大量の映画やドラマなどの動画メディアを大画面テレビで再生したり、風呂場や寝室でiPhoneで観たり、とか諸々する為にLinuxのファイルサーバーを常時起動しています。家のどこにいても携帯で数テラバイトに及ぶファイルの中から好きなメディアをVLCで再生したり、ファイル共有にも便利ですからね。

さらに、そのLinuxでMPDを稼働させ、スピーカーをつないで音楽も再生できるようにしています。もちろん普通のWindowsデスクトップにも入れて、PCで作業しながらの音楽再生にも利用しています。MP3ファイルの管理はiTunesにまかせちゃってますけれどね(iPhoneとの同期があるし、アルバムカバーの追加とか楽だから)。

もともとMPDは、Linuxのメディア・サーバーとして非常に人気があり、ヨーロッパや米国で良く使われています。日本では残念ながらまだ(日本語情報の量から判断する限り)あまり知られていない模様です。そもそも、Linuxで一般的なコマンドライン操作やパーミッションだの、IPアドレスの話しが出てきたり、テキストファイルでの設定など少々敷居が高い上に、英語でしか情報が無いのが原因かと思われます。とはいえ、テック界隈でもあまり認知度がなさそうなのは何故なんだろうと思ったりします。

(アプリのインストールやアクセス履歴を見ても、多いのは北米とヨーロッパ、その次にインドや南米、そして東南アジア、最後に日本、という感じで、異様に日本が少ない)

そんな訳で、ここでWindowsでのMPDの設定方法と使い方を、簡単に紹介したいと思います。

MPDのインストール

インストールと言っても、Windows版は単にExeをダウンロードして適当な場所に保存するだけです。

オフィシャルのMPDのサイトのダウンロードのページで、"mpd.exe for Windows x64"をクリックすると、mpd.exeというファイルが降ってきますので、それを保存します。基本どこでも構わないのですが、コマンドラインで操作する可能性を考えて、シンプルな場所が良いでしょう。ここでは以下の場所に保存します。

C:/mpd/mpd.exe

MPDの設定

mpd.exeと同じフォルダに

mpd.conf

というテキストファイルを作成します。このファイルでMPDの設定を記述します。

私の環境ではこんな感じです。

# MP3ファイルが存在する音楽フォルダの指定。

music_directory "C:/Users/hoge/Music/iTunes/iTunes Media/Music"

# プレイリストを保存するフォルダ(作成)

playlist_directory "C:/mpd/playlists"

# MPDのデータベースのファイルを保存するフォルダ(作成)

db_file "C:/mpd/data/mpd.db"

# MPDのログが書きだされるフォルダ(作成)

log_file "C:/mpd/data/mpd.log"

# MPDの状態が保存されるファイルの場所同じフォルダ指定。

state_file ".\\state"

# 接続ポート(デフォルト6600なので変更する必要はなし)

port "6600"

# 必要であればパスワード(権限と共に)の指定。変更する場合は、先頭一文字目を削除して@前を変更。

#password "hoge@read,add,control"

# インプット、コマンドラインでの操作の方法指定。

input {
  plugin "curl"
}

# オーディオのデバイス設定。基本デフォルトを使うようですが、使用デバイスを指定出来たりします。デバイス名で指定する模様。音が出ない場合はここが問題かと。

audio_output { 
  type "winmm"
  name "Speakers"

#device "Degital Audio (HDMI) (2- High Definition Audio Device)"
#device "Speaker/Headphone (Realtek Audio)"
}

 

フルの設定ファイルの例と説明は以下などを参照すると良いと思います。英語ですが・・・

mpd.conf · GitHub

MPDの起動とWindowsサービス化

この段階で、コマンドラインで(設定ファイルを指定してMPDを起動)

C:\mpd\>mpd mpd.conf

とやるとMPDを起動できるはずです(何やら書き出される場合もありますがエラーでなければ問題なし)。

テストで使うぶんにはこのままで良いのですが、コマンドライン(cmd.exe)の画面が表示されたままとなり不便なので、WindowsサービスとしてMPDを稼働させることが出来ます。Linuxでいうデーモンですね。

コマンドラインで(たしか管理者権限を利用してcmd.exeを起動する必要があったはず)以下のように打てば、サービス化できます。

sc create mpd binpath="C:\mpd\mpd.exe C:\mpd\mpd.conf" displayname="Music Player Daemon"

Windowsのシステム管理ツールの「サービス」ってアプリで確認できます。「遅延開始」が良いみたいです。

再生前の注意点

まず、MPDを使う上で必ず念頭に入れておきたいのは、音楽フォルダを変更したりした場合、MPDのデータベースのアップデート(更新)が必要となる、という事です。MPDは、先の設定ファイルに指定したフォルダ内の音楽ファイルを列挙してデータベース化します。MPDにデータベースを更新せよ、と指定しないと音楽ファイルを認識してくれません。

じゃ、どうやってそれをやるのか、というと、クライアントソフトが必要となります。公式で出ているクライアントはMPCといって、コマンドラインで使うものがあります。とはいえ、普段からコマンドラインのクライアントを利用する人は稀で、GUIタイプのクライアントを使います。

MPDのクライアント

2003年にMPDが公開されて以来、携帯アプリを含め様々なクライアントソフトが開発・公開されていますが、やはりLinux向けが多く、Windows向けはあまり多くはありませんでした。

・・・という事で作ってみました。

MPDCtrl, a MPD client for windows

MPDCtrl

いわゆる国際化済みですので、日本語環境では日本語の表示になります。

 

ソース諸々はGitHubで公開していて、オープンソースとして開発しています。

github.com

 

インストールというか実行するには、マイクロストのアプリストアで公開していますので、よろしければインストールして試してみてください。

www.microsoft.com

 

MPDへのアクセス

同じパソコンに入れた場合は、IPアドレス127.0.0.1」ポート番号はデフォルトでは「6600」で接続できるはずです。

 

技術的な余談

MPDCtrlの技術的詳細は、C#で開発し、出たばかりの.Net5をターゲットにして、UIは最高の表現力を持つWPFXAMLでデザイン、コードはMVVMパターンにしています。余計なライブラリは一切使っていません。

MPDとはTCPコネクションを張ってコマンドをやり取りします。アイドリング状態にしておくと、変更通知がつらつらと流れてくる、という感じです。

さらに余談

元々は携帯のアプリで簡単に操作できるシンプルなMPDクライアントアプリが欲しかったんです。しかし、iOS向けには良いアプリが無く・・・(今も無いですが)。以前はiPhone向けにとても良いアプリがあったそうなのですが、Appleには諸々古い開発プラットフォームを切り捨てるクセがあるため、ことごとく以前のアプリが動かなくなっているという状況でした。(しかもAppleのアプリストアは公開するが有料で、毎年お金がかかりますからね、無料のアプリでも)

しょうがない、じゃ自分で作るか、という気軽なノリで始めました。といってもiPhoneアプリの為に一からマックで開発ってのはやる気がせず、Windowsの環境で開発できるXamarinというプラットフォームを利用するつもりでした。これで開発すればiPhone向けとAndroid向けが一発で作れる、という事で。

ただ、2018年当時、Xamarineはまだこなれていなく、未成熟というか、開発途上の段階で、不安定というかまだこれから、という感じを受けたので、とりあえず動く段階まで作って断念、というか放置していました。

Windows環境で普段使っているの言語(C#)で携帯アプリを開発出来るのは凄いのですが、色々面倒で、マックを起動してそこでエミュレーターを動かしておいてWindowsから使う、という開発環境で、重たいというか遅い・・・。普通のデスクトップアプリだったら一瞬の起動が、エミュレーター立ち上げたりしていると何分も延々と待っていなければならなかったりするのです。だるかった。

そんなかんなで放置していたんですが、2020年になって、マイクロソフトから「.Net5」がアナウンスされて、WPFやXamarinなどのプラットフォームの統一がされる事になり、マイクロソフトがモバイル開発と共にネイティブのデスクトップアプリ開発へ回帰する、という方向性が見えてきたので、ヨシやったるか、と。開発者は利用するプラットフォームや技術の将来性に確信が持てなければ、膨大な時間と労力を投資というかコミットする気にはなれませんからね。

そこでまず、携帯アプリにする前に、まずはデスクトップアプリで完全版というかフルフィーチャーのMPDクライアントを作ってから、それをXamarinへ移植すれば良いじゃん、と。コアの部分はそのまんま100%再利用できますからね。

そんなかんなで始めたデスクトップ版ですが、かなり本格的になってしまい、いつの間にかバージョンが3.xとかになってしまいました。自分がヘビー使っているので、気になる点があればその場で改良・修正しているのに加え、他人様に使ってもらっているというのがちゃんと作る動機付けになっています。

モバイル版の方は、一応、現段階でXamarinでとりあえず動くのはあるのですが、やっぱりエミュレーターでUIデザインを確認しながら開発するのは面倒くさい・・・。しかも、Xamarinが統合されるのが2021年後半の.Net6になってしまう、というニュースが出て来て、まぁ本格的に手を出すのは来年かな、と思っています。というか、Xamarin.Formsよりも、Uno Platformを利用するかもしれない・・・

 *しかし携帯アプリの開発って、原始的というか、PCと比べて非力な上に小さな画面で機能も制約が多く、PCに慣れているとヘビーに使うのも開発するのもあまり楽しくないですね。携帯アプリはどこにでも持ち歩けるっていうのが利点なだけで、あとは携帯固有のカメラやGPSなどをメインの機能に組み合わせたアプリでないと、あまり存在意義が無い気もします。殆どのアプリがアプリである必要性すらなかったり・・・。別にそれブラウザで良くない?みたいな・・・。

 

 

はてなブログのAtom Publishing Protocolについて

 

Atomというのを覚えている人はどれくらいいるか分からないけれど、Atom(エディタ)に名前を取られて検索で出てこなくなってしまった悲しい仕様がありましてですね。

 

Atom Syndication Format

Atom Publishing protocol

 

実は今、このAtomのクライアントをC#/WPFで作っています。

github.com

 

このはてなブログも、一応、対応してくれてます。

はてなブログAtomPub - Hatena Developer Center

素晴らしいですね!

 

ただ、現状、はてなブログAtom対応にはあと一歩の点がいくつかあって、クライアントとしてはてなブログのAtomPubに対応したとしても残念ながら第三者向けツールとしての提供に耐えません。

気が付いた点を、忘れないようにまとめておきたいと思います。

 

1.No Service discovery in HTML page

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="https://hoge.jp/ja/xmlrpc.php?rsd" />

上記のは、WordPressのものですが、HTML の Header内に、Linkタグで、サービス文書へのリンクを記載しています。これはXML-RPCなどのRSD(Really Simple Discovery)形式での例ですが、下記はAtomでの例になります。

<link rel="SERVICE" type="application/atomsvc+xml" href="https://hoge.jp/ja/app" />

これがあると、クライアントは、HTMLページをパースして、エンドポイントを自動で機械的にゲットできます。しかも、Type属性で、Atomプロトコルだという事がはっきりと分かりますので、ユーザーへは単に「ブログのアドレスを入力してください」と、するだけで、とても分かりやすくなります。

 

以上の仕組みは、Service discovery と言います。

しかし、はてなブログには、このリンクがありません。

はてなブログAtomPub - Hatena Developer Center

を読むと、

https://blog.hatena.ne.jp/{はてなID}/{ブログID}/atom

手動で入力するようになっているようですね。しかも、独自ドメイン機能もあって、ややこしい事になっています。

ユーザーは、手動で入力して、なおかつ、Atom Publishing Protocolであることを、明示的に指定しないと、クライアントはAPIプロトコルを認識できません。

本来は、ユーザーは裏で動いているプロコルの種類などは気にせずに使えるようにした方がエクスペリエンス的に良いですよね。

はてなブログでも、Service discovery の仕様をブログのHTML内に記述して欲しいですね!

 

2.No Picture Collection in the service document

 はてなブログのサービス文書は、下記のものが返却されます。

<service xmlns="http://www.w3.org/2007/app">
 <workspace>
  <atom:title xmlns:atom="http://www.w3.org/2005/Atom">hoge</atom:title>
  <collection href="https://127.0.0.1/atom/entry">
   <atom:title xmlns:atom="http://www.w3.org/2005/Atom">fuga</atom:title>
   <accept>application/atom+xml;type=entry</accept>
  </collection>
 </workspace>
</service>

 

エントリコレクションだけしか含まれていません。

<accept>application/atom+xml;type=entry</accept>

つまり、画像などは投稿できません。

これ、辛いですね!

<collection href="http://example.org/blog/pic" >
 <atom:title>Pictures</atom:title>
 <accept>image/png</accept>
 <accept>image/jpeg</accept>
 <accept>image/gif</accept>
</collection>

こんな風に、写真画像向けのコレクションを追加して欲しいです!

 

3.No Category Collection in the service document

はてなブログの実装では、サービス文書にないので、カテゴリ一覧を取得出来ません。コレクションに下記のように、カテゴリ文書へのリンク(またはインラインで)を記載して、一覧で取得できるようにして欲しいですね!

<categories href="http://example.com/cats/forMain.cats" />

 またはインラインで、

<categories>
 <atom:category term="category1" />
 <atom:category term="category2" />
</categories>

 

4.PubContrl draft "no"

エントリの下書きへ戻す、が出来ないです!公開済みのエントリに対して、

app:control/app:draft

を、"no"とかにしてPUTすると、

BadRequest 400 Cannot Change into Draft

とのお返事を頂きます。

困りましたね!

 

以上です!

 

運営さんには、連絡したのですが!。。。