まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

2018年04月

業務の忙しさを言いわけに、IBM Cloud の新しい情報に疎くなっていました。で「なんか面白そうな API ないかなあ」とカタログを眺めていたら・・・

「金融」カテゴリに、、ん??
2018041901


こっ、これはっ!? もしやシグナイト!?
2018041902


おー、やっぱりシグナイトだ。世界中の株や為替を始めとする色々なマーケット情報を提供するシグナイトの API が IBM Cloud のサードパーティ API としても登録されていたのでした(知りませんでした、何か)。ただこの API はここからそのまま使えるわけではなく、別途アカウント登録が必要なようで、↓ひとつ進んだこのページの "Xignite" と書かれたリンクからアカウント登録に進みます:
2018041903


すると、この↓ページにジャンプします。ほうほう、シグナイト API は本来有料なのですが、IBM Bluemix(Cloud) ユーザー向けに7日間のトライアルが提供されている模様です:
https://market-data.xignite.com/IBM_Marketplace.html

2018041900


で、ここから名前やメールアドレスを指定して登録し、アドレスに届いたメールの内容を使って申請していきます。途中、以下のような画面になり、こんかいのトライアルで利用する API を1つ指定します(どうやらトライアルで利用できるのは一つだけのようで複数指定はできないようでした)。迷いましたが、個人的にも取引経験のある FX 向けの XigniteGlobalCurrencies を選択しました:
42


更に先に進み、アカウントのパスワードを指定してアクティベートします:
33


アクティベートが完了すると登録したアドレスに以下のようなメールが届きます。ここから "token" と書かれたリンクをクリックして、API 用のトークンを確認できます:
18


再びシグナイトのページに移動し、以下の赤枠部分に API 用のトークンが表示されています。API 実行時にこのトークン文字列が必要になります:
52


次にどんな API が提供されているのか調べてみます。シグナイトの API カタログページから今回選択した API(上記例の場合は XigniteGlobalCurrencies)を探し、その "API List" と書かれたボタンをクリックします:
26


すると指定した種類(XigniteGlobalCurrencies)の API 一覧が表示されます。ここでどんな API が存在して、どうすると実行できるのか、実際の実行結果がどんなフォーマットになるのか、といった情報を確認したり、実際に実行したりできます:
2018041904


試しにひとつ使ってみます。左側の API 一覧からリアルタイムレートを参照する GetRealTimeRate を選びます。すると画面右側が GetRealTimeRate 用に切り替わり、ここから各種パラメータを指定して実際に実行することができます(注 実行できるのはログイン時のみ)。以下の例では Request タブで
 Symbol: USDJPY(米ドル円レート)
 Result Format: JSON(結果を JSON で取得)
を指定しました。するとその下の URL が動的に切り替わり、この条件で API を実行する際のエンドポイント URL を示してくれます。下図ではモザイクをかけていますが、この URL にはトークンが含まれているので、そのままコピペ等で実際に確認することも可能な URL になっています。最後に下の "View Result" ボタンを押して実行します:
2018041905


成功すると実行結果が下部に JSON フォーマットで表示されます:
2018041906


実際の中身はこんな感じ、ほぼリアルタイムに値が取得できています(このタイミングで1ドルを買うと 107.374 円、売ると 107.368 円で、仲値が 107.371 円、という結果でした):
{
 "Outcome": "Success",
 "Message": null,
 "Identity": "Request",
 "Delay": 0.0167211,
 "BaseCurrency": "USD",
 "QuoteCurrency": "JPY",
 "Symbol": "USDJPY",
 "Date": "04/19/2018",
 "Time": "9:18:18 AM",
 "QuoteType": "Spot",
 "Bid": 107.368,
 "Mid": 107.371,
 "Ask": 107.374,
 "Spread": 0.006,
 "Text": "1 United States dollar = 107.371 Japanese yen",
 "Source": "SIX Financial Information"
}

トライアルだと7日間限定とはいえ、こんな便利な API が IBM Cloud から利用できるようになっていたんですねー。パラメータを変えて実行したり、他の API もここから同様に試すことができそうです。


なお、トライアルではない正式版(?)の API の価格については Flexible Pricing Model が適用されるようで、価格そのものはウェブからは確認できませんでした。興味ある方はこちらから問い合わせる必要がありそうです:
https://www.xignite.com/Pricing

 

 は IBM CloudantApache CouchDB と API 互換のある NoSQL データベースです。JavaScript で操作することができます。npm を使ってサーバーサイドで動かすこともできますが、ブラウザから JavaScript ライブラリをロードして、個々のブラウザ内で使うことも可能です。

特にこれをブラウザから使う場合、マスターデータはクラウドの IBM Cloudant で保持しつつ、必要なデータをユーザーのブラウザと同期して、ほぼすべての処理をローカルブラウザ内で完結させる(=時間のかかるDBアクセスをローカルDBだけを対象に行えばよくなるので、アプリケーションとしての安定性やパフォーマンス向上も期待できる)、ということが可能になります。とても強力な同期機能を持ったデータベースエンジンと言えます。
2018040900


この「同期」を具体的にどうやるか、という内容が今回のブログエントリです。


今回の説明では、サーバー側の DB を IBM Cloudant で用意することにします。IBM Cloud のライトアカウントを作成すると容量 1GB まで使えるライトプランの DBaaS が無料で用意できます。

で、この Cloudant DB をブラウザに同期・・・するわけですが、IBM Cloudant を使う場合はその前に1つ設定が必要です。標準状態の IBM Cloudant はクロスオリジンからのアクセスを許可していません。そのため、標準設定のままウェブブラウザから同期をとろうとするとクロスオリジンアクセスになってしまい、エラーとなってしまいます。したがってクロスオリジンアクセスを許可するよう、設定を変更する必要があります。詳しくはこちらにも記載していますが、curl コマンドと IBM Cloudant の API を使って IBM Cloudant の CORS アクセスを有効にするための設定を行います:
$ curl -i -u 'db_username:db_password' -XPUT 'https://db_username.cloudant.com/_api/v2/user/config/cors' -H 'Content-type: application/json' -d '{"enable_cors":true,"allow_credentials":true,"origins":["*"]}'

↑db_username, db_password は IBM Cloudant のインスタンスにアクセスするためのユーザー名およびパスワードです。


次にブラウザ内の JavaScript で DB の同期を行います。普通に「データベースそのものの同期をとる」のであれば話は単純で、以下のようなコードを記述するだけです:
  :
  :
<html>
<head>
<script src="https://cdn.jsdelivr.net/pouchdb/5.4.5/pouchdb.min.js"></script>
<script>
var localDB = new PouchDB( 'testdb' );
var remoteDB = new PouchDB( 'https://db_username:db_password@db_username.cloudant.com/testdb' );

remoteDB.sync( localDB, {
live: true, retry: true });
: :

まず CDN を指定して PouchDB のライブラリをロードします。そして IBM Cloudant のユーザー名(db_username)とパスワード(db_password)を指定して、'testdb' という名前のデータベースインスタンスを remoteDB 変数に代入します。これで IBM Cloudant 上のリモートデータベースを remoteDB から操作できるようになりました。同時にローカルブラウザ内に(同じ名前の)'testdb' という名前のデータベースインスタンスを作って localDB 変数に代入しています(こちらは作成時点では空です)。 この2つのリモート/ローカルデータベースを sync() 関数で同期するように指定しています。これによってこれら2つのデータベースインスタンス変数の内容は自動同期され、一方(例えばブラウザ内の localDB)に変化が起こるともう一方(サーバーの remoteDB)にその変化内容が勝手に反映される、という仕組みが実現できます。

ちなみに sync() 実行時の live:true オプションはリアルタイム同期の指定で、retry:true オプションは一度接続が切れた後に自動的にリトライして接続が戻った時に同期も復活させるための指定です。ここまでは超簡単です。


さて、本来やりたかったのはデータベースをまるごと同期するのではなく、データベースの一部だけを同期する、というものです。上記例だと remoteDB はサーバー側のものなので、全部で数ギガバイトになったりそれ以上になったりすることも想定しないといけないのですが、localDB はブラウザ内で作るものなのであまり大きくなっては困ります。そこで(一般的には部分同期とか Partial Sync とか呼ばれる方法で)特定条件を満たす一部の文書だけを対象にローカルに同期し、ローカルでの変更・追加・削除といった処理をサーバー側のマスターに同期し直す方法を紹介します。

PouchDB にも部分同期機能は存在しています。ただそこで「この条件を満たす文書だけ」を指定する方法がかなり限られていて、現時点では文書 ID を配列で指定する方法しかないように見えます(このフィールドがこの値で・・・みたいなクエリーではできないっぽい)。具体的にはこんな感じ:
  :
  :
<html>
<head>
<script src="https://cdn.jsdelivr.net/pouchdb/5.4.5/pouchdb.min.js"></script>
<script>
var localDB = new PouchDB( 'testdb' );
var remoteDB = new PouchDB( 'https://db_username:db_password@db_username.cloudant.com/testdb' );

var doc_ids = [ 'xxx', 'yyy', 'zzz' ];  //. 同期対象文書の _id 値配列

remoteDB.sync( localDB, {
doc_ids: doc_ids,
live: true, retry: true }); : :

上記例では 'xxx', 'yyy', 'zzz' という3つの文書ID(Cloudant 内だと文書の _id の値)を指定して、sync() 関数を doc_ids パラメータで配列指定しています。これだけで localDB には指定された3文書だけが同期され、削除を含めた変更があるとリモートにも即時に反映されるようになります。

したがって実装する場合はページロード時の最初に IBM Cloudant に対してクエリー API を実行して同期の対象となる文書(の ID 配列)をまとめて取得し、その ID 配列を指定して PouchDB と部分同期する、という流れになると思っています。この方法なら最初のロード時のネットワーク接続は必須になりますが、どのみちページをロードするにもネットワークは必須だし、同期をとった後はネットワークが切れても平気、というシステム構成が可能になります。


なお、一点だけ注意が必要なことがあります。この方法で部分同期した後に localDB に新たに文書を追加した場合です。部分同期の条件は doc_ids に指定された文書ID配列だったので、ここに含まれない新しい文書を追加してもサーバー側には同期されません。その場合は新たに doc_ids を指定しなおして(新しい文書の ID を追加して)改めて sync() 関数を実行する必要があります:
  :
  :
<html>
<head>
<script src="https://cdn.jsdelivr.net/pouchdb/5.4.5/pouchdb.min.js"></script>
<script>
var localDB = new PouchDB( 'testdb' );
var remoteDB = new PouchDB( 'https://db_username:db_password@db_username.cloudant.com/testdb' );

var doc_ids = [ 'xxx', 'yyy', 'zzz' ];

remoteDB.sync( localDB, {
doc_ids: doc_ids, live: true, retry: true }); : : function add( doc ){ //. ドキュメントを追加する処理 localDB.put( doc ).then( function( res ){ //. localDB に文書(doc)追加 doc_ids.push( doc._id ); //. 文書の _id 値を配列に追加 remoteDB.sync( localDB, { //. sync() 再実行 doc_ids: doc_ids, live: true, retry: true }); }).catch( function( err ){ console.log( err ); }); }

例えば上記例では add( doc ) 関数の中で doc に指定されたオブジェクトを localDB に追加する想定で処理を記述していますが、localDB.put() が成功したら doc_ids 配列を更新した上で remoteDB.sync() を再実行して同期条件を変えるようにしています。

現実問題としては追加なのか更新なのか(どちらも put() 関数を使う)、更新だとすると _rev の値も必要になって・・・とか、多少細かい実装が必要になることも事実ですが、一応これだけでローカルDBとその部分同期を使ったアプリの実装はできることになります。

問題は上述したローカルDBに同期したい文書の ID をどうやって調べるかですが、そこはやっぱり一度サーバーにクエリー投げるしかないのかなあ・・・


なお、PouchDB の API Reference はこちらを参照ください:
https://pouchdb.com/api.html


大阪府吹田市が市内の観光名所をテーマにしたデザインマンホール3種を作成し、先日公開されました:
吹田市がデザインマンホール蓋3種類 楽しみながら探して

この3種は「三色彩道の紅葉」、「ガンバ大阪」、そして「大阪モノレール」をテーマにしたもので、設置場所についてはヒントだけが公開されていました。ちょうど万博公園の「太陽の塔」の内部公開を見に行くタイミングと重なったので、この3つを探してきました。そしてそれぞれマンホールマップに投稿したので、以下は結果的に場所のネタバレを含む内容になっています(苦笑)。

















まず1つ目、「三色彩道の紅葉」


これは阪急千里線「北千里」駅からテーマになっている「三色彩道」に向かって歩いた途中の保育園の近くで見つけました。
http://manholemap.juge.me/page.jsp?id=5607739796554497828



2つ目、「ガンバ大阪」、ガンバのマスコットであるガンバボーイと、吹田市のイメージキャラクター「すいたん」がサッカーで共演しているマンホールです:



これは当然パナソニック吹田スタジアム・・・かと思いきや、結構難問でした。結論として最寄り駅は大阪モノレール公園東口駅で、ここから吹田スタジアムに向かって南下し、中国自動車道をくぐった直後の植え込みの中に設置されていました。↑の写真を見ると周囲が植え込みっぽくなっていることがわかると思います。

http://manholemap.juge.me/page.jsp?id=6283324744500361540



そして3つ目、「大阪モノレール」



こちらは大阪モノレール万博記念公園駅から東のららぽーとに向かって歩きます。そしてららぽーとに入るのではなく、万博記念公園に向かう橋も渡らず、ららぽーとの北側にある、モノレールと並行して伸びる側道(自転車の駐輪場? ちょっとわかりにくい)に入ります。そして入ってすぐの所に設置されていました。発見難易度はこれが一番難しかったと思います。

http://manholemap.juge.me/page.jsp?id=1433437503660013763


ちなみに、2番目のガンバマンホールに万博記念公園駅から向かう場合、この3番目のマンホールが設置されている側道をそのまま東に向かって歩き続けることで最短距離で移動できます(ららぽーとに入ったり、ぐるっと廻って吹田スタジアム経由で向かおうとすると手間取ることになります)。



なお、これら3種すべてのマンホールに suitable city という文字が表記されています。この "suitable city" を直訳すると「適度な市」とか「ちょうどいい市」みたいな感じだと思いますが、同時に suita(吹田)という部分が強調されていて、ダジャレマンホールになっています。こんなオチを隠し含めるあたりは大阪の意地なんでしょうかね。。。


吹田を訪ねる予定があり、これらのマンホールを探したいけど、滞在時間の関係などでどうしても効率よく周りたい、という方は参考にしてください。 (^^;


自分メモ兼情報緩募なブログエントリです。

SSH でサーバーにリモートログインして作業している途中で通信が途切れてしまう(プロセスが死んでしまうわけではなく、通信が切れてしまう)ケースがあります。自分が比較的頻度高くやっちゃうのは、電車内からテザリングを使ってリモートログインした先で Node.js のサーバーを動かしていて、地下鉄に入って通信が遮断しちゃうケースです。

これをやってしまって困るのは、例えば Node.js のサーバーを 8000 番ポートで動かしていたとすると、8000 番ポートへの listen が生きたままの状態で通信が切れてしまうことです。繋がっていれば Ctrl+C でサーバーを落とすことができるのですが、繋がっていないので Ctrl+C を入力する端末がありません。ということは再度リモートログインしてプログラムを修正して再度実行・・・しようとしても「そのポートは使われています」エラーになってしまいます。なんとかして元のプロセスを止めなければなりません。


※余談ですが、本来はこうならないように(途中で通信が切れてしまうことを想定して) screentmux などの端末のマルチプレクサーを使って作業するべきです。ただ今回はマルチプレクサーを使っていない時にこうなってしまった場合の対処方法についての話です。


以下で紹介する方法が正解かどうかはわからないのですが、自分の対処方法を紹介します。考え方としては「プロセスが残っているはずの SSH を探し出して息の根を止める」というアプローチです。

というわけで、まずは再度リモートログインした先で ps コマンドを実行して、自分が所有しているプロセスを一覧表示します(ちなみに実行コマンド内で `whoami` を実行していますが、自分の環境だとこの結果は dotnsf となり、dotnsf という文字を含むプロセスの一覧を表示しています):
$ ps -aux | grep `whoami`

root      4335  0.0  0.0  94924  7092 ?        Ss   08:19   0:00 sshd: dotnsf [priv]
dotnsf    4410  0.0  0.0  94924  4428 ?        S    08:20   0:00 sshd: dotnsf@pts/8
dotnsf    4411  0.0  0.0  23912  5620 pts/8    Ss   08:20   0:00 -bash
dotnsf    4654  0.0  0.5 935364 41736 pts/8    Sl+  08:37   0:00 node app
root      5167  0.0  0.0  94924  6964 ?        Ss   09:20   0:00 sshd: dotnsf [priv]
dotnsf    5243  0.0  0.0  94924  3408 ?        S    09:20   0:00 sshd: dotnsf@pts/9
dotnsf    5244  0.1  0.0  23800  5392 pts/9    Ss   09:20   0:00 -bash
dotnsf    5270  0.0  0.0  38376  3392 pts/9    R+   09:21   0:00 ps -aux
dotnsf    5271  0.0  0.0  15256  1012 pts/9    S+   09:21   0:00 grep --color=auto dotnsf
dotnsf   23891  0.9  1.4 1661748 118288 ?      Sl    2月23 651:40 /opt/couchdb/bin/../erts-7.3/bin/beam.smp -K true -A 16 -Bd -- -root /opt/couchdb/bin/.. -progname couchdb -- -home /opt/couchdb -- -boot /opt/couchdb/bin/../releases/2.0.0/couchdb -kernel inet_dist_listen_min 9100 -kernel inet_dist_listen_max 9100 -kernel error_logger silent -sasl sasl_error_logger false -noshell -noinput -config /opt/couchdb/bin/../releases/2.0.0/sys.config
dotnsf   23940  0.0  0.0   4512   856 ?        Ss    2月23   0:00 sh -s disksup
dotnsf   23941  0.0  0.0   4232    72 ?        Ss    2月23   0:05 /opt/couchdb/bin/../lib/os_mon-2.4/priv/bin/memsup
dotnsf   23942  0.0  0.0   4364    76 ?        Ss    2月23   0:00 /opt/couchdb/bin/../lib/os_mon-2.4/priv/bin/cpu_sup
dotnsf   26173  0.0  0.0  45276  3140 ?        Ss    2月15   0:00 /lib/systemd/systemd --user
dotnsf   26174  0.0  0.0 210940  2152 ?        S     2月15   0:00 (sd-pam)
dotnsf   31713  0.0  0.0  11140   312 ?        Ss    3月30   0:00 ssh-agent
  (↑青字が実行コマンドです)


結果の中で注目すべきは赤字にした2行です。dotnsf が sshd から pts(仮想端末)を使っているプロセスが(左から2列目の数値でいうと) 4410 と 5243 の2つあります(実際にコマンドを実行した結果は3つ以上みつかるかもしれません)。この2つのうち、どちらかは今自分がリモートログインに使っている仮想端末のプロセスで、もう1つは今回のターゲットとなる行方不明のプロセスです。このどちらか正しい方のプロセスを kill することで目的を達成することができます。

というわけで、「どちらかは正解、間違えると自分が死ぬ」という下図のような状況なわけです(笑):
jigenbakudan_kaitai_shifuku




ここでの問題は「どちらが目的のプロセスかを判断する方法」なのですが、これって正解あるんでしょうか? (^^; 明確な方法があったら自分も知りたいです。

自分がやっている判断方法としては2つあります:
・時刻(左から9列目)を見る。どちらかは自分がログインしているプロセスということは、そのプロセスの時刻は自分がログインした時刻になっているので、自分が現在ログインしているプロセスをなんとなく判断できる。
・プロセス番号(この例だと 4410 と 5243)は大抵小さい方が古い。現在のログインに使っているプロセスの方が新しいはず。


で、この基準で考えるとプロセス番号 5243 の方が現在使っているプロセスに該当するので、もう1つの 4410 のプロセスが息の根を止めるべきプロセス、と判断できることになります。ただこの考え方は経験的なもので、もしかすると別の確実な方法があるかもしれません(誰か知っていたら教えてください)。


(↓追記)
who コマンドで自分が現在いる TTY を調べることができる、という指摘をいただきました。確かに使えそうです。
$ who
dotnsf   pts/8        2018-04-12 21:00 (192.168.X.X)

(↑追記)


というわけで、4410 を kill することにします:
$ kill 4410

まあ仮に間違えていたとしても自分が強制ログアウトされるだけなので、そしたらもう一度リモートログインしてもう1つの方を kill し直せばいいんですけどね。。

で、これで上手く元のプロセスを消すことができていれば、再度実行した時に「そのポートは使われています。。」エラーは消える、はず。

 

IBM Cloud(Bluemix) から提供されている NoSQL データベースの DBaaS である Cloudant は読み書きのための REST API が公開されています。各種プログラミング言語から HTTP ベースの API を実行してデータを読み書きすることが可能です。

ただ、これらの API には一般的な CORS(Cross-Origin Resource Sharing) の制限がかかっており、ウェブブラウザの JavaScript からは読み書きができないように設定されています。この CORS 制限を無効にする方法が分かったので、ブログで紹介する形で手順等を紹介します。

まず今回ブラウザからアクセスする対象とするデータベースをこちらとします。pouchdb というデータベースで、現在4件のドキュメントが登録されています:
2018040900


このデータベースに簡単にアクセスするため、今回は PouchDB ライブラリを使うことにします。PouchDB は軽量かつ CouchDB(Cloudant) 互換のデータベースです。この PouchDB を CDN(//cdn.jsdelivr.net/pouchdb/5.4.5/pouchdb.min.js) からロードして、データベースオブジェクトを作り、その中の全文書を取り出して表示する、という処理を実装すると↓のような感じになります:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title>CORS check</title>
<script src="//cdn.jsdelivr.net/pouchdb/5.4.5/pouchdb.min.js"></script>
<script>
var cloudant_db_url = 'https://USERNAME:PASSWORD@USERNAME.cloudant.com/pouchdb';

var db = new PouchDB( cloudant_db_url );

db.allDocs( { include_docs: true } ).then( function( docs ){
  console.log( docs );
}).catch( function( err ){
  console.log( 'error' );
});
</script>
</head>
<body>
</body>
</html>

主な処理内容を簡単に解説します。まず CDN から PouchDB ライブラリをロードし、Cloudant のデータベース URL を指定して、データベースオブジェクトを作ります(上記の USERNAME は Cloudant のユーザー名、PASSWORD は同パスワードです)。そして allDocs() メソッドで全文書を取り出して結果を console.log() でコンソールに表示する、という内容の JavaScript を含む HTML になっています。


この HTML を HTTP サーバー上に配置してウェブブラウザからアクセスします。取得結果はコンソールに表示されるので、あらかじめコンソール画面を表示(FireFox であれば F12 キー)しておきます。その状態でブラウザから同ページにアクセスすると・・・コンソールには「クロスオリジン要求・・」というエラーが表示されます。これはつまり Cloudant 側でクロスオリジンからのアクセスを許可していないため、アクセスは拒絶され、そのエラーが表示されています。これが Cloudant のデフォルトでの挙動です:
2018040901


では Cloudant の CORS アクセス(クロスオリジンからのアクセス)を有効にしてみます。curl コマンドの使えるターミナルから、以下のコマンドを実行します:
$ curl -i -u 'USERNAME:PASSWORD' -XPUT 'https://USERNAME.cloudant.com/_api/v2/user/config/cors' -H 'Content-type: application/json' -d '{"enable_cors":true,"allow_credentials":true,"origins":["*"]}'

このコマンドでは認証用の ID とパスワード、HTTP ヘッダの Content-Type: application/json を指定し、/_api/v2/user/config/cors パスに対して、CORS アクセスを有効にするようデータを POST して実行しています:

2018040902


上記のように {"ok": true} という結果が返ってくればコマンドは成功し、クロスオリジンからのアクセスも許可されています。試しに再度同じ HTML ページを(リロードするなどして)表示すると、今度は allDocs() メソッドが成功し、期待通りに(4件の)データを取得し、コンソールに表示できているはずです:
2018040903


これで Cloudant の API をブラウザ(の JavaScript )からも直接実行する術が確保できました。これでウェブブラウザの HTML から直接 Cloudant を操作したり、ウェブブラウザ内の PouchDB と連携することもできるようになります。



(参考)
How to use CORS with a Cloudant account

CORS


このページのトップヘ