実験)DBを使わないで同じ処理をしようとすると・・・

自分のbotで、フォロワーさんからお願いされた事を覚えておいて、後でお仕事する的なことをやってみたことがあるのですがDBのテーブルを利用して実装してしまったので、もし普通のファイルを利用したらどうなるかなとちょっと考えてみました。
seriarizeかCSVファイル形式でデータを保持して、プログラム中で配列に展開してメンテナンスするのが、簡単かなとゴニョゴニョやってみましたが、出来上がったファイルを人間が見て直感的にわかりやすいと言う意味ではCSVが良さそうかなーと言うわけで

続きを読む

Replyするbotの構造

普通はプログラム等組む場合、仕様書を書いたりするのですが、Twitter botの場合、趣味の範疇なもので、イキナリ作っておりましたが、もし書いてみたらどんな感じかなという話。自己満足なので、適当に読み飛ばしていただけますと幸い。

最低限の機能を考えると…

0.準備処理:接続に必要な情報等々準備
1.Timeline取得:Twitter Timelineを取得する
2.返信対象があるか判断: なければ処理終了
3.返信準備:返信用のメッセージの準備
4.Status/update: Twitterで用意した返信メッセージでステータス更新
5.まだ返信処理を続行するなら2に戻る、なければ処理終了

続きを読む

TwitterAPIでimageが上手く扱えない

Twitter APIで、account/update_profile_imageを使えば、アイコンが変更できる筈なのですが、今のところ不成功。

BASIC認証については、こちらを参考にさせていただいて上手くいったのですが、OAuthが今のところ上手くいっていません。

Googleここを見る限りなんとかなりそうな雰囲気なのですが・・・

自分のメモ用に上記を日本語訳しておくと

続きを読む

Twitter botの テスト環境、本番環境

他のbot作成者の方がどのように、コード管理や、テストを行われているか知らないのですが、自分はこんな感じでやっていますというお話。

[Twitter アカウント]

通常自分が使っているアカウントの他に

1.botアカウント 本番用
2.botアカウント テスト用
3.テスト用アカウント x 2

 の4種類のアカウントを利用しています。
 そのうち 1,2のbotアカウントについては、OAuth対応のため、アプリケーション登録済み。

[ローカル/サーバー]

ローカル(自宅PC)
サーバー(さくらインターネット

※本当は、自宅PCの環境を本番環境として利用しているさくらと PHPのバージョンやら何やら一致させた方が安全なのですが、そこまで、最先端なことをしていないし、大丈夫かな?とずるずるそのままでやっています。
  ただ、実際のところは、自宅PC上と、サーバに上げた時で動作が違うことも発生するので、そこは、try & errorで潰すという泥臭い作業を行っています。

[コード管理]

 本当はSVN等利用して、きっちり管理すると良いのですが、1世代以上前に戻る必要が生じたことも現時点は、無いので、大きな変更を行う前にごっそりバックアップを取っておく位で、通常は、稼働中、開発中の二世代を違うディレクトリに入れて、開発、テストが終わったら本番(稼働中)ディレクトリに移すという原始的管理中。

 ローカル、サーバそれぞれに、開発中、稼働中の2種類のディレクトリが存在し

  1. ローカル 開発中ディレクトリでコード変更
  2. ローカル環境 開発中ディレクトリ&テスト・アカウントで テスト
  3. ローカル 開発中ディレクトリ ⇒ サーバ 開発中ディレクトリ に変更したphpファイルコピー
  4. サーバー環境 開発中ディレクトリ&テスト・アカウントで テスト
  5. テストが全てOKであれば ローカル 開発ディレクトリから ローカル、サーバの稼働中コード用ディレクトリに ファイルコピー
  6. サーバ環境 本番用ディレクトリのコード&本番アカウント で最終チェック

 といった、感じに開発したコードのテストと本番への実装を行っています。(ていう程偉そうなものでもないですが)

 なお、ユーザーの接続情報は、よく配布されているコードですと、プログラムにベタ書きですが、自分の場合は、プログラム本体とは別のファイルに入れて、開発ディレクトリには、テスト・アカウントの情報、本番用ディレクトリには、本番アカウントの情報をあらかじめ仕込んでいます。
こうしておくと、開発用のディレクトリにあるコードを実行すれば、テスト・アカウントで接続し、本番用のディレクトリ内のコードを実行すれば本番用アカウントでTwitterに接続できるので、開発⇒本番 で、アカウント情報を書き変える手間が省けます。*1

*1:実際には、接続情報への外部からの不正アクセス避けのため、ユーザー情報のファイルは、web rootより上の階層のディレクトリに格納しており、bot用のプログラムを格納しているディレクトリには、そのファイルへのアクセス方法を入れています

デバッグし易くしよう!(おまけ) testLog Class をサンプルコードに適用した例

前回のデバッグ用Class testLogをサンプルコードに組み込んでみた例です。

開発時、運用時などの状況により、表示の有無、出力範囲の制御を次の二つの定義を組み合わせで制御できます。

//DEBUG処理の切り替え 本番運用時にはFALSEに変更すること
define('DEBUG', TRUE); //デバッグ
//define('DEBUG', FALSE); //本番運用時

testLog::setdispLogF( TRUE ); // ログを画面表示するか? TRUE/FALSE

また、メインプログラム側で、ログファイル名に日付を加え、日付ごとにログファイルが分かれるようにしています。

//ログ処理準備
$Kyou=date("Ymd",time());

$logDir='./log/'; //ログディレクト
$logFname=$logDir.'test_syori_log'.$Kyou.'.txt';//ログファイル名
require_once("test_log.php"); //test class
testLog::setLogfile($logFname); //ログファイル名の指定

続きを読む

デバッグし易くしよう! 7:  デバッグ用のClass

特にStep6のログファイルの出力のことを書きましたが、
毎回error_log...で、ログファイルの出力先等を記載するのは面倒臭い。
ログファイルに出力したいことと、画面に表示したいことは同じ場合も多い。
どのプログラムでもデバッグ用にやりたい作業はだいたい同じ
ということで、実際の自分のプログラムではデバッグ処理用のClassを作成して使い回しています。本当に使っているものはもっと複雑というかラーメンかスパゲッティか的な物なのですが、少し単純化してみたものをご参考までに載せて説明させて頂きたいと思います。*1

Step7: デバッグ用Classを使う

仮に testLogと名付けたClassを作成しました。
このClassを利用してできることは以下の通りとなります。

1.任意のテキスト文字列を表示/ログファイルに出力する。
2.ログファイルへの出力に際しては、以下の内容も追加した状態で出力される。
  a.処理が行われた時間
b.プログラム名
3.ログファイルに、
  プログラムの開始、終了時刻および処理時間を出力することも可能
4.文字列の表示、非表示は切り替え可能

プログラム側でのこのClassの利用例は次のようになります。

<?php
require_once("test_log.php");  //testLog class
testLog::setLogfile('./logfile/test_log.txt'); //ログファイル名の指定
testLog::setProgname( 'testprogram_name' ); // プログラム名
testLog::setdispLogF( TRUE ); //  ログを画面表示するか? TRUE/FALSE

testLog::save_msg('処理スタート','====['.__FILE__.']==');

// メインの処理

testLog::save_msg('処理終了','=================================');
testLog::keikazikanLog();  
?>

上のようなコードを含むプログラムを実行した場合。
./logfile/test_log.txtには、以下のような形式でログを出力することができます。

"2010-01-12 01:13:48","0.8619","testprogram_name","処理スタート","====[C:\(中略)\testprogram.php]=="

"2010-01-12 01:13:48","0.72220","testprogram_name","処理終了","================================="
"2010-01-12 01:13:48","0.72433","testprogram_name","[ 2010-01-12 01:13:48.8614 ]-[ 2010-01-12 01:13:48.72419 ]","  開始からの処理時間= [0.63805]sec"

画面の表示は下記のようになります。

testLog: 処理スタート,====[C:\(中略)\testprogram.php]==

testLog: 処理終了,=================================
testLog: [ 2010-01-12 01:13:48.8614 ]-[ 2010-01-12 01:13:48.72419 ],  開始からの処理時間= [0.63805]sec

見ておわかり頂けると思いますが、最初に出力対象のログファイル名、プログラム名、画面表示の有無を設定してしまえば後は、

testLog::save_msg('text1','text2');

のように、表示、出力したい情報を文字列形式にしてセットするだけです。なお、2つ目の項目は省略も可能です。

以下、実際のtestLog Class となります。

*1:http://www.sound-uz.jp/php/note/startDebug のdebugクラスを物凄く参考にさせていただいております。

続きを読む

デバッグし易くしよう! 6:  ログファイルに処理記録を残す

ここまでは、処理の進行状況や、変数の値などを表示する方法を紹介してきましたが、実際に本番サーバー上で、botの運用を開始してしまうと、毎回の処理状況を付きっきりで目視できる訳ではありません。
PHPのerror_log関数(マニュアル)を利用すると、ログとして任意のエラーメッセージをファイルに書きだすことができます。
これを利用して、処理のログをファイルに書き出してみることにします。*1

Step6 ログファイルに処理記録を残す

error_log関数を利用してログをファイルに書き出す方法は簡単です。例えば、syori.txtというファイルに"プログラムを実行しました”というメッセージを書き出したいのであれば、下記のように書くだけでOKです。

<?php

error_log("プログラムを実行しました",3,'syori.txt');

?>

これを今までも利用しているサンプルコードに埋め込むんで、step1で追加した、echo文をログファイルに出力するようにしてみると例えば、次のようになります。

*1:error_log ( string $message [, int $message_type = 0 [, string $destination [, string $extra_headers ]]] )関数
エラーメッセージを Web サーバのエラーログ、 TCP ポート、あるいはファイルに送ります
第2引数$mesage_typeに"3"をセットした場合に、第3引数Rdestinationで指定したログファイルに第1引数で指定したエラーメッセージが書き出されます。

続きを読む