2011年2月アーカイブ

先日、奥さんがアメリカンビスケットを焼いてくれました。

京都に本店があるアメリカンケーキのお店「松之助」さんのビスケットを買ってきたのですが、それがたいそう美味しかったのです。

それに刺激を受けて、作ったようです。

ところで、この料理、ケンタッキーフライドチキンでも、「ビスケット」という名前で販売していますが、何回見ても、「スコーン」と区別がつきません。何が違うんでしょうか。

昨年途中で中断した、「奥さんに代わって料理を作る日」。

久々に復活です。

今年最初の料理は、きのこリゾット、ポークソテー、あさりとトマトの野菜スープ。

それぞれ、以下のレシピを参考にしました。

「きのこリゾット」=>献立・料理レシピ@nifty

「あさりとトマトの野菜スープ」=>こうちゃんの簡単料理レシピ

(調味料の配分や材料などは、かなりオリジナルにしてしまってますが・・・)

好評だったようで、良かった良かった。

リゾットは初めて作りました。みんな簡単、というけれど、きちんとつくると以外に手数がかかるんだな、という印象でした。

来月は、どんな料理をつくろうかな。

和食でもつくろうかな。

前回までは、入力フォーム表示・登録ロジック(registForm.php)と、入力データチェックロジック(registCheck.php)の2ファイルで、ユーザー情報の登録処理を行いました。

今回は、入力フォームに情報入力後、確認画面を経て、登録完了を行うようにロジックを分けたいと思います。

流れとしては、以下のようになるかと思います。

今回は、メールアドレスとパスワードのチェックについて考えてみます。

パスワードのチェック欄を増設する

その前に、テストで作成したフォームを修正します。

テストでは、パスワードの入力欄は1つのみでしたが、入力欄を2つに分け、パスワード確認のために2回入力させるようにします。

1つ目のパスワード入力欄のnameは「password」

2つ目のパスワード入力欄のnameは「password2」としました。

続いて、メールアドレスのチェックを行います。

前回は、ユーザー情報の登録に当たって、最低限のチェックと登録まで、を実装しました。

今回は、入力されたユーザーIDのチェックを行います。

ユーザーIDの条件定義

まず、登録ユーザーIDの仕様を以下のように定義しました。

1. ユーザーIDは必須
2. 登録済みのユーザーIDは再登録できない(重複チェック)
3. ユーザーIDは半角英数字のみで構成される
4. 最低4文字以上ないとNG。(3文字以下のIDを許可しない)上限32文字まで。

上記に従って、ベリファイ用のルーチンを考えました。

1,2は前回実装済みなので、今回は3・4の処理について考えます。

僕は高校時代、演劇部に所属しており、

「大学生になったら、演劇も続けて、大好きな歴史の勉強もしたい」

と考え、入学したのが早稲田大学でした。

(大学時代は、今は作家として有名になった「古川日出男」さんと一緒に、演劇をやっておりました)

第三舞台は、ちょうど僕が入学する頃に、人気が出始めた劇団です。

初めて第三舞台を見たときは、あまりの凄さにカルチャーショックを受けました。

「演劇って、こんなに面白いんだ！」と、打ちのめされる思いがしました。

2001年、「ファントム・ペイン」を最後に、10年の活動封印を宣言した「第三舞台」。

今年でちょうど、10年。

復活するのかな？

「虚構の劇団」もノってきているし、このまま封印が続くんじゃないかな・・・

と思っていたところ。

先日、放送作家をやっている先輩と、お酒を飲んでいるときに

「知らないの？今度復活公演やるらしいよ。ニュースに出てたよ」

と、教えてもらいました。

な、なんとびっくり！

登録ユーザーのログイン・ログアウトの次は、実際にユーザーをユーザーDBに登録するためのロジックを開発してみます。

今回の流れ

今回の作業概要は以下のとおりです。

• ユーザーがID・メールアドレス・パスワード・ユーザー名を入力。登録ボタンを押すと、ユーザーDBに登録される
• 登録の際、ユーザーIDとメールアドレスの重複をチェックする。重複データがあった場合はエラーメッセージを表示して再入力を促す。
• 登録の際に、データのエスケープ処理を行い、SQLインジェクションを回避する

今回は、PEAR::AUTHを利用してログインしたユーザーの、タイムアウト処理です。

PEAR::AUTHでログインしたユーザーのタイムアウト処理

ウェブサービスを利用していると、必ずといっていいほど、ログイン済みユーザーのタイムアウト処理を行っています。

タイムアウト処理は、大きく分けると、次の2つがあると思います。

• ログイン後、一定時間が過ぎたら自動的にログアウトする
• ログイン後、なにもしない時間が一定時間過ぎたらログアウトする

先日の予告通り、少しづつ手を動かして、いろいろ触っております。

最初は、ユーザーのID・パスワードに基づく、認証システムの実装。

PEAR::AUTHを使って認証するフローを考える

認証システムはいろいろと作り方があるようですが、今回はPEAR::AUTHを使うことにしました。

まずはデータベースにテスト用のID・パスワードを登録して、ログイン・ログアウトだけをテストします。

ロジックは以下のとおり

1. 入力フォームから、ログインID、パスワードを入力
2. 入力データが問題ない場合、ログインセッションを生成、ログイン済みメッセージを表示。
3. ログインが失敗した場合、ログインエラーメッセージを表示して、フォームに戻る。
4. ログアウトボタンを押すと、ログアウトして、セッション終了。

フローチャートにすると、以下のようになるでしょうか。

先日の近況報告で、肺炎になってしまったことを書いたところ、思いのほか大勢の方からお見舞いのお言葉をいただきました。ご心配をおかけしました。

先日、かかりつけの病院に行ったところ、「だいぶ良くなったので、もう薬はやめて、通院もしなくてよいでしょう」とのお言葉をいただきました。

完治、とまで行くかは分からないですが、ようやく治った、と言ってよいかな？

ずいぶん長い間患いましたが、これからは徐々に外出時間も増やしていきたいと思います。

せっかくですので、気づいたことをメモ書き致します。