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

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

タグ:cloud

「ウェブ魚拓」というサービスをご存知でしょうか?ネット上のウェブサイト(URL)を独自にキャッシュして保存するサービスのことです。ネット上のウェブサイトがなくなってしまったり、内容が変わったりしても、その保存したタイミングでのウェブサイトを後からでも参照できるように残す、というサービスです。

このウェブ魚拓もどきのサービスを Node.js 向けに作って、ソースコードを公開しました:
https://github.com/dotnsf/urlrec

2019020801


まず、この公開したサービスではあらゆる全てのサイトでキャッシュを残せるわけではありません(いわゆる「対策済みサイト」に対しては、この機能は無効です)。残せるサイトの場合は独自フォーマット(本当は MHTML にしたかったんですが、色々難しそうだったので、画像だけインライン展開するフォーマットで HTML と画像を記録できるようにしました)でキャッシュを記録します。つまり取得時点でのテキスト内容と画像をキャッシュして記録します。

また記録先として IBM CloudIBM Cloudant サービスが必要です。必要に応じて IBM Cloud のアカウントを作成し、IBM Cloudant サービスインスタンスを作成しておいてください:
2019020802


ソースコードを入手する前に、IBM Cloudant インスタンスを利用するための接続情報を確認しておきます。作成したサービスインスタンスの「サービス資格情報」メニューから「資格情報の表示」を選択(見当たらない場合は1つ新規に作成してから選択)すると JSON フォーマットの接続情報が表示されます。この中の username と password の値を後で使うことになるので、このページを開いたままにしておくなどしてコピー&ペーストできるようにしておきます:
2019020803


では改めてソースコードを入手します。https://github.com/dotnsf/urlrec から git clone するか、下図のように zip をダウンロード&展開してソースコードを手元にコピーします:
2019020804


ソースコードが入手できたら、settings.js ファイルをテキストエディタで開きます。そして exports.db_username の値を先程確認した IBM Cloudant の接続情報の username の値に、exports.db_password の値を同じく password の値に、それぞれ(コピー&ペースト等で)書き直して保存します:
exports.db_username = '(username の値)';
exports.db_password = '(password の値)';
exports.db_name = 'urlrec';
: :

Node.js が導入されていればローカル環境で動かすことも可能です。その場合は以下のコマンドを実行します:
$ npm install  (依存ライブラリを導入)

$ node app  (実行)

server stating on XXXX ...

成功すると上記のように "server starting on XXXX ..." と表示されます。この XXXX は数字になっているはずで、ウェブ魚拓サービスはこのポート番号で待ち受けている、ということを示しています。


では実際に使ってみましょう。先程確認した XXXX を使って、ウェブブラウザから http://(サーバー名 または IP アドレス):XXXX/ にアクセスします。以下のような画面が表示されれば成功です:
2019020805


画面上部の "URL" にキャッシュしたいページの URL を入力して "CHECK" ボタンを押すとプレビューが表示されます(このプレビューが表示されないページは非対応だと思ってください)。下の例では試しに自分のブログの1ページを指定してみました:
2019020801


そしてプレビュー画面で(必要に応じてテキストコメントを入力した上で) "Record" をクリックするとキャッシュがシステムに保存され、先程の画面内に一覧表示されます:
2019020802


この画面で一覧内の一番左の列(赤枠部分)をクリックすると、別ウィンドウが開いてキャッシュされた内容を確認することができる、というものです(元の URL の記事が削除されていても見れるようになります):
2019020803


UI的にもまだまだシンプルすぎる所があったり、元のページのスタイルの再現性など、まだまだ改良の余地はあると思っていますが、基本機能は実装できていると思ってます。MIT でソースコードを公開しているので、役に立つ場があればご自由に使っていただきたいです。

そろそろプロ野球のシーズン開幕前順位予想とかが始まるので、それらを片っ端から記録しておこうかなあ、と邪な考えを持っていたりします。 σ(^^;


個人的な野望としてはこれを元に更に改良してブロックチェーンと組み合わせて真偽証明付きにして・・・って感じかなあ。

2019 年最初のブログ投稿に、普段感じる事が多いけどあまり触れていなかった点について書いてみようと思います。ちょっとだけマジメな話です。


拙作「マンホールマップ」は 2010 年からサービスの開発を始めて、ほぼ同時期からサービスを開始しています。色んな人のアイデアを参考にさせていただくことはありますが、基本的には私一人で開発を行い、管理を含めた運営を行っています。もう8年以上続けていることになります。今は当時と比べてもクラウドをはじめとする時代背景が大きく変化し、個人でウェブサービスを開発・管理・運営する環境が整っていると感じていますが、そういった業務で開発・運営するのは異なる部分について、一度まとめておこうと思いました。


【背景】
まずはいい意味での違いを。ここ数年のクラウド環境の充実、そして低価格化によって、個人がウェブサービスを運営しやすくなったと感じています。

後述もしますが、ウェブサービスを「作る」ことに関しては開発環境さえ整えればいい話ですが、それを公開して運営するにはドメインの取得に加え、インターネット上に公開された24時間稼働が可能なサーバー機を用意する必要があります。企業で運営する場合、専用サーバーや専用回線を調達する方法もありましたが、個人には(主にコスト面で)敷居の高いものでした。また以前から「ホスティングサービス」と呼ばれるサービスでインターネット上のサーバーを借りることはできましたが、技術的な制約も大きく、開発上のハードルが上がってしまうものでした。

この点において、世の中でクラウドが広まり、特に PaaS 環境が広まってきたことで、サーバー環境の準備や構築だけでなく、(標準で用意されているものを使うことで)ドメインや証明書の取得まで不要になる時代になったことを実感します。こうなると個人でもサービス/アプリケーションを開発できれば、その運用を開始するまでのハードルはぐんと低くなっていると感じます。


以上のように個人がウェブサービスの運営を開始するまでのハードルは低くなりましたが、一方で実際に運営する段になると業務で行う場合とは異なる点を意識する必要があることも実感するようになりました。そんな背景における違いを、実際に運営する中で気付いた範囲で言及してみようと思います。



【個人で開発・運営するのは業務で行う場合と何が違うのか?】
一言でいえば個人運営だと「全部自分でやる」点が違います。何を作るのか、どこまで作るのか、いつまでに作るのか、どんな画面にするのか、どんな実装で実現するのか、プログラミング言語は、データベースは、OS は、どこで動かすのか、ドメイン名/ホスト名は、コストはいくらまで出せるのか、問い合わせ対応は、フィードバック対応は、・・・ 決めるのも実行するのも自分一人です。

一方、業務で行う場合、もちろんその企業の規模とかにもよると思いますが、多くのケースで分業制が考えられます。開発部分ひとつ取っても、デザインと実装は担当分野が分かれるケースが多いですし、インフラの構築とアプリの開発は別チームというケースも少なくありません。が、個人だと分ける相手がいません。「UIデザインは苦手」とか言ってられないのです。

また開発後の運用やサポートも自分で行います。業務だと電話サポート窓口があったりしますが、普段は本業を持つ個人開発者がサポート業務に従事することはできません。サーバーが止まっていても気づける人がいない※のです。 となると「なるべくサポートが不要になるような設計」をはじめから意識して作る必要があります。マンホールマップの例だと不適切な画像を投稿する人がいたらどうするか?という問題がありました。ここは Twitter アカウントとの連携で不適切な画像を投稿しにくくする、という形にしました。要は投稿時には Twitter アカウントによるログインが必要で、不適切な画像を投稿すると Twitter 側にもバレる、というリスクを利用者に課したのです。そうすることで、そういった愉快犯的に不適切画像を投稿する人を少しでも減らそうという試みでした。幸いにしてサービス開始から悪質な投稿をする人はほとんど表れていません。ある程度の効果はあったのかもしれませんが、こういったサービス設計段階における考慮も必要になるのでした。

※ちなみに上述の「サーバーが止まっている場合も気づける人がいない」問題は Google Search Console のサーバーエラーをメールで通知する機能で解決できます。自分で解決する必要はないのですが、こういった世の中のツールを知っていたり、調べたりする能力も必要になってきます。


【ドメインの問題】
自分でサービスを作るだけならずっと以前から(自分の手元のPCに開発環境を用意すれば)できたことです。以前はいざ公開・運営するとなった場合に「どこで」公開するか、という問題がありました。何というホスト名(ドメイン名)で公開するか、という問題です。 試験的・限定的に公開するだけなら IP アドレスでも(特殊なポート番号でも)いいと思うのですが、公開するとなるとそうも言えません。

加えて SSL 証明書の問題もあります。最近は外部 API と連携する際の条件として https 通信が可能なことが求められることも珍しくなくなりました。ドメインを取得した上で SSL 証明書を取得し、https 通信を有効にすることが必須となることもあります。

もちろんオレオレ証明書でも NG ではないし、最近は SSL 証明書も安く取得できるようになってはいますが、ドメインの取得は無料というわけにはいきません。つまりいくばくかの運用コストが無視できなくなってしまいます(コストについて詳しくは後述します)。またその手続や設定を運用開始までに済ませて置かなければならないのだとすると(上述の「一人でやらなければならない」という条件も考慮して)運用開始までの負担が大きくなってしまうのでした。

ただ、この辺りも昨今のクラウド環境の、特に PaaS と呼ばれるサービスを利用することで、特に存在を意識しなくても使える DNS やドメイン名があったり、はじめから SSL が利用可能になっていたりするものもあります。こういう環境が広まっていくことは個人開発者としても大歓迎です。


【コストの問題】
クラウドはウェブサービスの運用を開始するまでの技術的なハードルを大幅に下げてくれることを上述しました。では難しいところはクラウドにおまかせする形で、クラウドベンダーの環境で公開することに問題はないのでしょうか?

現実問題としては「コスト」が問題となるケースがあると思っています。アプリケーションサーバー1台とデータベースサーバー1台での運用であれば、最悪1台の IaaS の中に同居させてしまう形にして、理論上はこの1台ぶん最低限のサーバーの月額コストだけで運用することができます(月 500 円程度から可能です)。

ただ実際には「最低限のサーバーの月額コスト」ではまかなえないケースが多くなると思っています。その最低限のサーバー1台に搭載されたメモリ量で動くのか? IaaS の中にデータベースを同居させたディスクの容量は足りるのか? 足りたとしてもデータのバックアップをどう考えるか? 上述のドメインに関わるコストも無視できません。  ・・いずれもクラウドサービスにコストをかけることで解決できることが多いのですが、そのコストは経費ではなく個人負担なのです。クラウドのデータベースって、冗長性とかバックアップとか考えなくていいのは確かに便利ですが、(安価な仮想サーバーほど)安くはないですよね。。それを個人で、しかも毎月負担できるのか、、という問題です。とはいえ万が一バックアップがないサーバーが死んでしまったら・・・と考えると、公開する以上は考慮しないといけない問題なわけで、、、


これも私の話で恐縮ですが、自作ウェブサービスのほとんどはクラウドで公開していますが、マンホールマップは 2019 年1月時点で自宅サーバー運用しています。一番に理由はコストで、上述の要素を考慮してクラウドサーバーを用意すると毎月コストが結構な額になってしまい、それなら自宅に安いサーバー(というかPC)を買ってなんとかしたほうが現実的、という判断に至ったのでした。


【で、結局・・・】
まとめると、こんな感じでしょうか:

- 昨今のクラウド環境の充実によって、開発したウェブサービスを公開して運用するのは安価かつ容易になった。
- 非機能要件を無視できる間はそれでもよいが、ある程度データが溜まってくると万が一の際のバックアップなどを無視できなくなる。
- その辺りまで考慮しはじめると「クラウドが安い」と言い切れなくなってくる。がんばって自宅ネットワーク内のサーバーを公開したほうが安上がりになるケースも。
- 自分一人で管理する前提でサービスレベルを考慮/設計する必要がある。
- 個人ウェブサービスは開発/運営するのは(一通り全てをある程度のレベルでこなさないといけない、という意味で)すごくいい勉強になる。



↑実は最後の一文を言いたくてこの長いブログエントリを書きました。業務経験としては個人開発や個人運用は評価しにくいのかもしれませんが、これを一人でこなせることも、一人でもこなせるような設計をしていることも、本当はもっと高く評価されてもいいんじゃないかなあ、、、と思っているのでした。

クラウド環境が広まったことで個人ウェブサービスを運用するハードルは確実に下がっています。この環境を活用して、色々な人がウェブサービス運営に興味を持ってもらえると嬉しいし、それは技術者としての(業務にも関わる)スキルアップに確実につながると思っています。

(この記事は IBM Cloud アドベントカレンダー 2018 に参加しています。2日目の記事です)

先日、以下のブログエントリを公開しました。本エントリはその技術的な補足と、試験的な意味も含めてアプリ URL を一般公開する内容になっています。
お絵かき LIFF アプリを作ってみた

2018112200


技術的な説明の前に、まずは一度使ってみていただきたく、このアプリを(一時的に?)公開することにしました。少し面倒ではありますが、以下の手順で実行できるようにしたので、まずは一度使ってみてください。

①スマホに LINE アプリをインストール(お絵かきアプリは PC 版 LINE からは使えません)

②LINE を開いて誰かとのメッセージ画面(グループ LINE 可)の中に以下の文字を入力してリンクメッセージとして送信する(この作業だけは PC の LINE アプリから行ってもよい)
line://app/1624220123-mbERyVgb

2018120101


③スマホの LINE 画面内から②で送信したリンクメッセージをタップ
2018120102


④LINE 内でお絵かきアプリが起動します。ペンの色と太さを変えながら指でお絵かきします。
2018120103


⑤間違えたら reset か、一度終了してから再度リンクメッセージをタップしてやり直し。
2018120104



⑥描き終わったら post でお絵かきが画像として LINE にメッセージ送信されます(右上の×を押してアプリを終了する)
2018120105


・・・というものです。LINE はスタンプ文化が有名ですが、スタンプを持っていなくてもその場でお絵かきして送るとか、他には地図を書いて送るとか、いろいろな使い方が考えられると思っています。現状、上記のリンクを LINE のメッセージとして一度送っておく必要があり、そのリンクをタップした時に起動する、という使い方になってしまいます。技術的に興味がある人もない人も是非お試しいただきたいと思っています。


以下、このアプリの技術的な解説になります。

このアプリは LINE の新しい開発フレームワークである LIFF(LIne Front-end Framework) を使って開発しています:
https://developers.line.biz/ja/docs/liff/overview/


LIFF は LINE 内で動作するウェブアプリケーションのプラットフォームです。「LINE 内で動作する」という点と「ウェブアプリケーション」であることがキーワードです。上記のように LINE 内で特定リンクをタップすることで起動し、その中身は HTML5 と JavaScript で記述されたウェブアプリケーションです。LIFF の詳しい仕様等は上記の開発者向けページを参照いただきたいのですが、要するにパブリックインターネット上に HTML5 ベースのウェブアプリを作って、そこを参照するような LINE リンクを作っておくことで LINE アプリ内でその HTML5 ページを起動することができます。また LIFF SDK の JavaScript API を使うことで、その HTML5 アプリの情報を起動元である LINE 側に(メッセージとして)送信することも可能です。

今回作ったアプリの場合は HTML5 の Canvas を使ってお絵かきアプリを作成し、その中に描かれた絵を動的に画像に変換して、画像を貼り付ける形でメッセージを送ったことにしています。その結果、HTML5 Canvas 内に描かれた絵を LINE 上で画像添付したかのように送信させることを実現しています。

この仕組の HTML5 ウェブアプリケーション部分と、画像添付部分を IBM Cloud 上の Node.js ランタイムと IBM Cloudant を使って実現しています。HTML5 Canvas 内に描いた画像を動的に PNG 画像へ変換し、Node.js ランタイム上の REST API を使って取得し、(LIFF の場合、画像はオリジナル以外にサムネイルが必要なので)サムネイル画像を生成して IBM Cloudant データベース内に添付ファイルとして保存します:

2018120106


画像が添付できたら、今度はその画像を外部から参照できる URL を用意します。具体的には Node.js ランタイム内に Cloudant 内に格納した画像ファイルを参照できるような URL(REST API) を用意します。そして HTML5 内の LIFF SDK を使って、画像ファイルの URL をメッセージとして送信して、添付画像を付与したメッセージ送信と同じ処理を行います。これでお絵かきで作成した画像が添付されたかのような振る舞いを実現できます:
2018120107


という形で現在は実現しています。 つまり現在はこのアプリを使って作成した画像は IBM Cloudant 内に保存されるように実装されています。現在の運用環境では、このデータベースの容量にも制約があるので、しばらくはデータベースをリセットしながら運用することになります。もしうまく送信できない場合は僕がデータベースのメンテナンスを忘れていて、容量オーバーになっている可能性があることをお伝えしておきます(気付いたタイミングでリセットするようにします)。

また、この公開アプリのソースコードはこちらで(MIT ライセンスで)公開しています。IBM Cloud を使う前提で記述されたコードですが、自分なりに改良したい人がいればうまく活用してください:
https://github.com/dotnsf/line_liff_doodle


これまで LINE の API といえば Messaging API で、bot のようなバックエンド側を操作するアプリを作るには有用だったのですが、やっとフロントエンド側を操作できる API(というかフレームワーク)が出てきてくれました。公開ページ上で HTML5 アプリを置いて運用することになるので、実質的にクラウドを活用する形態が多くなると思います。そんな時に IBM Cloud の上記構成程度であれば無料のライトアカウントでも運用できるので、公開したソースコードを是非色んな人に使ってみたり改良してみてほしいです。

LINE の新しい開発フレームワークである LIFF(LIne Front-end Framework)の存在を教えていただいたので、試しに使ってみました。

この LIFF 最大の特徴はスマホの LINE アプリ内で HTML5 の Web アプリケーションを動かすことができる、という点です。この Web アプリケーション内で LIFF の SDK を併用すると、アプリケーションからLINE にメッセージや画像(やスタンプ)を送ることも可能です。

この LIFF を使って指で画面にお絵かきをするような HTML5 アプリを作り、その絵を LINE アプリに送信する、というアプリケーションを作ってみました。LINE はスタンプを送信する文化がメジャーですが、その延長で自分でその場でお絵かきした画像を送る、という使い方を想定したアプリケーションです。ソースコードは github で公開したので、興味ある方は実際に試してみてください:
2018112200



なお、今回提供しているソースコードでは IBM Cloud の NoSQL マネージド・データベースである Cloudant を使っているので、IBM Cloud のアカウントも必要です。無料のライトアカウントもあるので IBM Cloud のアカウントをお持ちでない場合はあわせて取得してください。


【IBM Cloudant の準備】
今回紹介するアプリケーションでは IBM Cloundant のインスタンスが必要です。IBM Cloud にログインし、インスタンスを1つ作成して、あらかじめ画像格納用のデータベースを用意しておきます。なお無料のライトプランの場合、Cloudant には 1GB までのデータしか格納することができないという点をご了承ください。

まず IBM Cloud にログインし、「リソースの作成」から IBM Cloudant を追加します。IBM Cloudant は「データベース」カテゴリ内に存在しています:
2018112201


作成時のロケーションはどこでも構いません(下図では「シドニー」を使っています)。ただ認証方法は従来の方式が利用できる方("Use both legacy credentials and IAM")を選択しておく必要があります:
2018112202


また価格プランも任意で構いませんが、Lite プランの場合は無料です。ただし 1GB までしかデータを格納することはできません。最後に「作成」をクリックしてインスタンスを作成します:
2018112203


Cloudant インスタンス作成直後の画面です。まずここから目的の(画像格納用の)データベースを作成するため、Cloudant のダッシュボードに移動します。下図の緑のボタンをクリック:
2018112204


Cloudant のダッシュボード画面に移動しました。データベース一覧が表示されていますが、作成直後の場合は何も存在してません。ここで「Create Database」をクリックして、データベースを作成します:
2018112205


作成するデータベースの名前を指定します。デフォルトでは "doodledb" を使います(後述の settings.js 内で指定されている名称と一致している必要があります)ので、とりあえず doodledb と入力して「Create」します:
2018112206


doodledb データベースが作成され、doodledb データベース内の文書一覧画面に移動しました(当然中身はありません)。左上の "<" 印をクリックしてデータベース一覧に戻ります:
2018112207


データベース一覧に戻りました。先程とは変わって、"doodledb" が一覧に含まれているはずです。これでデータベースの準備ができました:
2018112208


次にこのデータベースへ接続するための情報を確認します。IBM Cloud の画面に戻り、「サービス資格情報」タブを選択します。サービス資格情報は(この時点では)存在していないはずなので、「新規資格情報」ボタンをクリックして作成します:
2018112201


設定項目は変更せずに「追加」します:
2018112202


資格情報が追加されると先程の画面内に「資格情報の表示」メニューが追加されているはずです。ここをクリックして内容を確認します:
2018112203


資格情報の内容が JSON テキストで表示されます。今回必要なのは "username" と "password" の値です。これらの情報を後で利用するので、メモしておくか、コピペできるようにしておきます:
2018112204


これで IBM Cloudant の準備はできました。


【ランタイム(Web アプリケーション・サーバー)の準備】
次に LIFF が参照する Web アプリケーションサーバーを作成します。このサンプルは Node.js 上で動作するサンプルですが、今回は IBM Cloud 上にアプリケーション・サーバーを作成することにします(これもライトプランの無料枠内で作成することができます)。

Cloudant の時と同様に IBM Cloud にログイン後にリソース作成で「コンピュート」カテゴリの「SDK for Node.js」を選択します:
2018112201


ロケーションは「ダラス」を選択します(するとドメインは "mybluemix.net" となります)。そして「アプリ名」にアプリケーション名称を指定します。下図の例では "linedoodle" というアプリケーション名称としており、この場合のエンドポイント URL は https://linedoodle.mybluemix.net/ となります。なおアプリ名は他で使われていないものを指定する必要があります。自分の名前や日付を指定するなどして、ユニークなアプリケーション名称を指定してください。最後に「作成」をクリックします:
2018112202


しばらく待つとアプリケーションサーバーが起動します。これで LIFF アプリからアクセスできるパブリッククラウド上にアプリケーションサーバーが用意できました:
2018112203


【LINE Developers の準備】
LINE の LIFF アプリを作成するには LINE Developers でのチャネル登録が必要です。LINE Developer において新規にチャネルを作成します:
2018112204


チャネルの種類は「Messaging API」を選択します:
2018112205


アプリ名とプラン(Developer Trial)を選択し、作成します:
2018112206


作成すると、このチャネルにアクセストークンが割り当てられます。「アクセストークン(ロングターム)」と書かれた項目の値をこの後で使うことになるのでメモするか、コピペできるようにしておきます:
2018112207


また、ここで LIFF アプリとしてのアプリ URL を作成しておきましょう。LIFF タブを選んで「追加」ボタンをクリックします:
2018112209


名称、サイズ(Full または Tall のいずれかを選択)、そしてエンドポイント URL(上述の Node.js アプリケーションのエンドポイント URL)を入力して「保存する」をクリックします:
2018112210


すると LIFF アプリが登録され、LIFF URL が確認できるようになります。この LIFF URL は実際に LINE からアプリケーションを起動する際に利用します:
2018112208


これで LIFF アプリの登録も完了しました。あと少し。


【アプリケーションの準備】
上記で作成したアプリケーション・サーバーに HTML5 アプリケーションをデプロイします。まずはソースコードを入手します。github のリポジトリからソースコードをダウンロードまたは git clone して入手します:
https://github.com/dotnsf/line_liff_doodle

ソースコードがダウンロードできたら settings.js ファイルを環境にあわせて編集して保存します:
exports.db_username = '(Cloudant の username)';
exports.db_password = '(Cloudant の password)';
exports.db_name = 'doodledb';
exports.app_port = 0;

exports.base_url = 'https://(アプリケーション名).(ドメイン)/';

exports.line_access_token = '(LINE Developer で取得したロングタームアクセストークン)';

  :
  :

最後にこのアプリを上記で作成したアプリケーションサーバーにデプロイします。IBM Cloud では cf コマンドを使ってデプロイするので、未導入の場合は cf コマンドをダウンロード&インストールしてください:
https://github.com/cloudfoundry/cli/releases


そして cf コマンドを使って IBM Cloud へ IBM ID でログインし、アプリケーションをプッシュ(デプロイ)します:
$ cd (ソースコードのあるフォルダ)
$ cf login -a https://api.ng.bluemix.net/ -u (IBM ID)
$ cf push (アプリケーション名)

ここまでの作業が全て成功すると LIFF アプリが IBM Cloud 上にデプロイされ、LINE のチャット上で LIFF URL をクリックすると、LINE 上で同アプリケーションを呼び出すことができるようになります。


【LINE で動作確認】
では実際に LINE を使って動作確認してみます。上述で取得した LIFF URL ("line://app/" で始める文字列)をコピー&ペーストするなどして LINE のメッセージとして表示させます:
2018112201


この LIFF URL 部分をタップすると画面下部から LIFF アプリである HTML5 の Web アプリケーションの画面が表れます。今回の Web アプリはお絵かきアプリとなっていて、指でキャンバス上をドラッグして絵を描くアプリとなっています。色やフォントの太さを変えたり、失敗したら "reset" ではじめからやり直すこともできます:
2018112202


たとえばこんな絵を描いてみました。書き終わったら "post" をタップします:
2018112203


描いた絵が LINE の会話内に画像として表れます。その場でステッカーを作って送るような感覚です:
2018112204


・・・というアプリを作ってみたのでした。いかがでしょう? ちなみに iPhone 版の LINE でのみ動作確認しています。Android 版 LINE でうまく動かなかったらごめんなさい。


以前から似たようなアプリを Twitter 向けに作ってみたりしていて、同じようなのを LINE 向けにも作れたらいいなあ、と思っていました。が、LINE にはクライアント側を操作できる API が提供されておらず作ることができずに諦めていました。 が、今回 LIFF の存在を教えていただいて、「これならできるかも・・」と期待してがんばってみたら、なんとか実現できた、という経緯です。アプリ実装の詳細についてはまた別の機会にでも。

ある意味で LINE のステッカービジネスを根底から否定(苦笑)するアプリなので、あまり LINE 受けはよくないかもしれません。(^^; でも教えていただいたおかげで実現することができました。この場をお借りしてお礼申し上げます。


そうそう。繰り返しになりますが、IBM Cloud の(無料の)ライトアカウントを使って作成した場合、データベースには 1GB ぶんの画像しか格納できません。定期的にデータを削除するとか、データベースを消して作り直すとかして対応してください。



(参考)
LIFF API リファレンス


IBM Watson をはじめとした IBM Cloud から提供されているサービスの認証方法に IAM が採用され始めています。以前に IBM Watson サービスで IAM を使う方法についてはこちらのブログエントリでも紹介しました:
IBM Watson のアプリケーションを IAM(API Key) 認証/認可に移行する


今回は IBM Cloudant を IAM で利用する方法を紹介します。なお 2018/11/22 時点で IBM Cloudant が IAM でないと認証できなくなるというアナウンスがされているわけではないことを書き添えておきます(つまり現時点では従来の認証方法と併用されており、すぐに移行作業が必要になるわけではありません)。


まずは IAM に対応した IBM Cloudant のサービスインスタンスを用意する必要があります。現在 IBM Cloudant のサービスインスタンスを作成すると IAM のみで利用するタイプか、従来の認証と IAM の両方が利用できるタイプかを選択して作成することができます。どちらでもいいのですが IAM 対応のインスタンスを用意します。

まず IBM Cloud のダッシュボードからリソースの追加を行い、データベースカテゴリ内の "Cloudant" を選択します:
2018110701


作成時の認証方法において "Use both legacy credentails and IAM(従来の方法と IAM)" を選択して作成します:
2018110702


これでどちらの方法でも認証できるインスタンスが作成できました:
2018110703


クレデンシャル情報を確認するため、サービス資格情報を参照します。資格情報が作成されていない場合はあらたに1つ作成します:
2018110704


作成した資格情報を選択して参照します:
2018110706


JSON テキスト内に "apikey" と書かれたキー文字列が含まれていることを確認します。この値は後ほど利用します:
2018110707


では IAM で IBM Cloudant を使う Node.js アプリケーションを作成してみます。ソースコードはこんな感じになります:
var fs = require( 'fs' );

//. https://www.npmjs.com/package/@cloudant/cloudant
var CloudantLib = require( '@cloudant/cloudant' );

var options = {
  url: "https://xxxxxx-bluemix.cloudant.com",    //. Cloudant URL
  plugins: {
    iamauth: {
      iamApiKey: "(上記 apikey 文字列)"
    }
  }
};
var cloudant = new CloudantLib( options );
var db = cloudant.db.use( "mydb" );

db.list( { include_docs: true }, function( err, body ){
  if( err ){
    console.log( JSON.stringify( err, null, 2 ) );
  }else{
    console.log( JSON.stringify( body, null, 2 ) );
  }
});

Cloudant へのアクセスには @cloudant/cloudant パッケージを利用しています。このパッケージが既に IAM 対応済みで、上記のように URL と apikey 文字列を指定することでデータベースに接続することができ、データベースインスタンス生成後は従来通りの各種関数が利用できるようになります。


このページのトップヘ