LINE BOT用サンプルコードをコピペして使っても、うまく動作しない!もう終了した「BOT API Trial Account」のコード使ってませんか?
Line Botを作ろうと思い、Google検索でひっかかるサンプルコード的なものをコピーしても、全く動作しないしどこがおかしいのかもわからない。(エラーも出ない)なんて事に遭遇していませんか?
私は、まさにそれにはまりましたので、その原因と対策を記載いたします。
まず、私がはまったのは、匿名チャットボットを作ろうとして、下記の記事をコピーしても、全く動作しないという事象です。
こちらの記事のサンプルコードを、HerokuでDeployした、index.phpとして動作させました。
事前に、別のサンプル的なコードは動作していましたので、Deployがうまくいっていないという事もなく、アクセストークンなども何度も確かめました。
結果、分かった事なのですが、どうもこのサンプルコードは、2016年11月16日に廃止された、「BOT API Trial Account」用のコードのようです。
詳細は、こちらをご覧ください。
つまり、この記事をかいている2017年6月11日時点では使えないという事です。
現在は、LINE BUSINESS CENTERの記事にも書かれている通り、新しく始まった「Messaging API」というサービスで、同様のものが作れそうですが、もしも、「BOT API Trial Account」用に書かれたサンプルコードにある機能を実装しようと思うと、コードはそれに合わせて書き換えなくちゃいけないようです。。。
何がどう変わっているかは、下記の記事にあります。
(これだけでコードの書き換えが完全にできるかどうかはわかりませんが。。。ひとつの目安として。。。)
もし今からLINE BOTを作ってみようという方で、まずはGoogleの記事にあるサンプルコードをコピペして使ってみようという方は、そのコードが、「BOT API Trial Account」時代のもの(2016年4月7日~2016年11月16日)でないか確認しましょう。
簡単に見分ける方法は、POSTの送信先が、https://trialbot-api.line.me/になっていたら、「BOT API Trial Account」時代のソースなので、今は使えません。
現在使える、「Messaging API」は、POSTの送信先が、https://api.line.me/になっています。
APIの使い方については、LINE BUSINNES CENTERに詳細があります。
https://devdocs.line.me/ja/#messaging-apidevdocs.line.me
ちなみになんですが、LINE BUSSINESS CENTERから、Messege APIの登録をしようとすると、「Developer Trailを始める」という選択肢がありますが、これは、Message APIのアカウントのタイプであって、「BOT API Trial Account」とは関係ありません。(私は、ここでもはまりました)
WindowsからLine NotifyにcURLで送信した際にCouldn't resolve host ~というエラーが出てしまう
Line Notifyに通知を送るのに、WindowsからcURLを使ったところ、タイトルのように
curl: (6) Couldn't resolve host 'Bearer' curl: (6) Couldn't resolve host 'Pydu1 ~中略~ ZgB'' {"status":401,"message":"Missing authorization header"}
というエラーが出てしまい、Line Notifyにメッセージ通知が行われませんでしたが、解決できましたので記載します。
まず、前提条件としまして、Line Notifyに登録し、cURLからメッセージを送るという流れは、こちらの記事の通りにやりました。
この記事の通りにcURLを使ってコマンドを打つと、上記のエラーになると思います。
解決先は、
'Authorization: Bearer ACCESS_TOKEN'
の部分を
"Authorization: Bearer ACCESS_TOKEN"
と、シングルクォーテーションをダブルクォーテーションに変えることでした。
正しく動作するcURLコマンドをきちんと書くとこうなります。
curl -X POST -H "Authorization: Bearer ACCESS_TOKEN" -F "message=ABC" https://notify-api.line.me/api/notify
ACCESS_TOKENの部分には、Line Notifyから取得したアクセストークンが入ります。
どうも、cURLを投げるOSによって、シングルクォーテーションで囲ったり、ダブルクォーテーションで囲ったりする必要があるようです。
Windowsの場合は、ダブルクォーテーションしか受け付けないようです。
このあたりの差異は、OSによって改行コードが違ったり、パスの区切り文字が違っているなどと同じような問題なのかもしれません。
また、このエラーの解決にはこちらの記事が参考になりました。
Line Notifyの使い方の記事はたくさんありますが、群を抜いて詳しく書かれていると思います。
ここまで書いてくれないと、素人には難しいですね。。。
Virtual Boxで新規作成した仮想マシンを起動した際に「FATAL:Could not read from the boot medium! System halted.」と表示される場合の対処法
Virtual Boxで新規作成した仮想マシンを起動した際、
となってしまうのは、起動するドライブにOSのISOイメージがマウントされていないからです。
Virtual Boxで仮想マシンを起動するためには、「新規作成」で仮想マシンを作成しただけでなく、起動ドライブにOSのiSOイメージをマウントする必要があります。
ちなみに、OSのISOイメージというのは、iOSというファイル形式のデータファイルで、つまり、OSのプログラムの事です。
Virtual Boxで仮想マシンを新規作成するというのは、あくまでも入れ物だけで、OSのプログラムが無いと、OSは起動しません。
また、マウントするというのは、起動ドライブに、IOSイメージのファイルを保尊する事です。
まとめると、どこかからOSのプログラムを調達してきて、それを、「起動ドライブに保存する。」という意味になります。
OSのiOSイメージの調達に関しては、「OS名 + ダウンロード」などのキーワードで検索すれば、入手方法はすぐに見つかるでしょう。
ISOイメージを入手できたら、「設定」 -> 「ストレージ」を選択し、光学ドライブのCDのマークのところから、ダウンロードしたIOSイメージを選択します。
これでIOSイメージのマウント完了です。
VB.netなど、.NET Framework環境で動作するアプリケーションからOracleに接続方法には何がいいですか?
PSRとは不具合修正パッチの事です。~Oracleの用語~
「DDL」はテーブルの定義、「DML」はテーブルの操作~OracleのSQL文の種類~
Oracleを使ったお仕事をしていると、会話の最中やドキュメント修正時に、「あれ?この場合どっちだったっけ?」って事になったりしませんか?
私はよくなりますので、この機にきちんと書き記しておこうと思います。
略称 | 名称 | 日本語名 | 意味 |
---|---|---|---|
DDL | Data Definication Language | データ定義言語 | CREATEやDROPなど、データの定義に関する事を行うSQL文。 |
DML | Data Manipulation Language | データ操作言語 | SELECTやINSERTなど、データの操作に関する事を行うSQL文。また、SELECTに関しては、DMLとは別に、Query(問いあわせ)という分類にされることもあるようである。 |
SQL文の種類が問題になる場合、上記の2つが対象となる場合が多いと思うが、他にも、DCL(Data Control Language)という分類をする場合もあるようです。
DCLとは、GRANT、REVOKEなどが対象になるようですが、これは、標準のSQLではなく、Oracle固有の命令も含まれるので、Oracleのマニュアルのは、DCLという表記は無いようです。
ORACLEで'REDO'が付く用語の意味がごちゃごちゃになりませんか?まとめてみました。
Oracleの用語で、'REDO'と名前が付くものがいくつかあって、ごちゃごちゃになりがちなのでまとめます。
用語 | 意味 |
---|---|
REDOエントリ | SELECTやINSERTなど、ORACLEの変更履歴の事。REDOエントリは、始めにメモリ領域であるREDOログバッファに書き込まれ、commitのタイミングでオンラインREDOログファイルに書き込まれる。また、アーカイブモードの場合は、オンラインREDOログファイルの一つが書き込みいっぱいになり、次のファイルにスイッチするタイミングで、アーカイブREDOログファイルに保存される。 |
REDOログバッファ | ORACLEの変更履歴が書かれたファイル。SELECTやINSERTなど、データベースに何らかの変更が加えられた際の情報は、メモリ領域であるREDOログバッファに書き込まれる。REDOログバッファはメモリ領域でありサイズに制限があるので、ある程度でオンラインREDOログファイルに書き込まれる。変更履歴がオンラインREDOログファイルに直接書き込まれず、まずはREDOログバッファに書き込まれるのは、アクセス負荷を減らす目的。 |
オンラインREDOログファイル | REDOログバッファに書き込まれた変更履歴が、commitのタイミングで書き込まれるファイル。また、オンラインREDOログファイルは最低2つ以上存在し、ひとつのファイルがいっぱいになったら、次のファイルに書き込まれ、すべてのファイルがいっぱいになると、また最初のファイルに上書きされるという仕組みで、循環して書き込まれ続ける。また、オンラインREDOログファイルは、ORACLEの障害時に復旧に用いられるが、オンラインREDOログファイルに障害が起こると復旧が出来なくなるため、オンラインREDOログファイルを多重化する事も可能。 |
アーカイブREDOログファイル | オンラインREDOログファイルは、循環して書き込まれるので、古い情報は随時消えてしまう。そのため、古い情報を残す場合には、アーカイブREDOログファイルに残す必要がある。アーカイブREDOログファイルは、オンラインREDOログファイルがひとついっぱいになり、ファイルが切り替わるタイミングで、書き込まれる。オンラインアーカイブREDOログファイルに |