プレビューの実装

CMSを作っていると、必ず必要になる機能がプレビュー。入力中のデータが意図した通りに画面に反映されるか、正確に確認出来なければいけない。
過去にやってしまったミスとして
＊プレビュー用のテンプレートを分離
＞テンプレートの二重管理が必要となり、怠るとあっという間に差分が生じる。当然、プレビューの意味が無い。
＊プレビュー用のロジックを分離
＞テンプレート同様、差分が生じる。結果、表示にも差異が生じるため、プレビューの意味を成さない。
＊プレビュー用にデータを分離
＞テンプレート同様（ry
本番と同様にレコードを保持し、プレビューのステートにしておくだけでいい（フラグよりもステートが吉）。無駄に_prevや_tempのような一時テーブルを用意すると、結局、二重管理の問題でやられる。
＊画面遷移をともなう確認作業で混乱
＞プレビュー用のURLを別にしてしまうと、画面遷移をともなう確認作業時に本番ページへ飛んでしまい、どこまでがプレビューだったのか分からなくなり、挙句不具合扱いされてしまう。
プレビューはあくまで見た目のチェックであり、動作までは確認できなくてもよいのでは？とも言われそうですが、ユーザはボタンがあれば押すんです。押して予想外の動作をすれば、不安になります。利用者目線で作っておくことが、ひいては自分たちの余計な作業を減らすことにつながります。それに「これは仕様」でゴリ押しばかりしていると、不信感がたまりますからね。
プレビュー時に気をつけることとして
＊副作用に注意
＞本番同様のロジックを呼び出す場合、その（意図しない）副作用に注意。たとえば、アクセス解析の類や、ロギング、メールの送信、キャンペーンの応募処理などが、意図せずして実行されないように気をつける。ただし、確認のためにこれらの処理を動かしたい場合は、本番と同等の動作確認ができるように本番同様のロジックを利用するのが好ましい。
＊一般ユーザに見られないこと
＞プレビューの状態ではページはまだ未公開なので、一般ユーザに閲覧されてはまずい。URLにprev=1などのパラメータをつける手段はあまりに安易でなんの制限にもなっていない。管理者がURLをコピーしてばらまいてしまうこともある（そんなバカなと言うなかれ。過去にセッション情報を含んだURLをメルマガで送信した事件もあった）。URLに依存しない制御機構が安全。
ポイント
＊URLやテンプレート、ロジックは極力本番と同じものにする
＞別なロジックやテンプレートを利用すると、それは実質的にプレビューではなくなっている。本番で同じ処理、見た目になることを保証するには、本番と同じ環境にしなければならない。
＊プレビューステートはセッションにて管理。
＞CMS管理画面側でフロント閲覧時のステートを変更できるようにしておくのが理想的。プレビューステートで閲覧したときには、プレビュー用の差異を吸収するようにロジック・テンプレートに細工をしておく。若干テンプレートが煩雑になるかもしれないが、二重管理の苦痛に比べればマシ。
通常の公開やプレビューの他に、デバッグのステートも用意しておいて、プリントデバッグなどを仕込んで置くと、いざというときに便利。でも、いよいよテンプレートが汚くなっていくので両刃の剣。非プログラマがテンプレートを管理しているなら、避けるべき。
＊テンプレートやロジックは最初からステートに対応させておく
＞後付けでプレビュー周りの機構をつけるくらいなら、あらかじめテンプレートもロジックもステート対応にしておく。これで実質すべてのページや処理がステート対応になる（ちょっと言い過ぎかも）。
少し工夫すれば、テストにも応用可能（Botにテスト用のステートを付加してアクセスさせるなど）
＊ページのタイトルに【プレビュー】と表示しておく。
＞タイトル変数を組み立てるロジックにちょっと加工するだけで実装可能。プレビュー中かどうかすぐに分かり、余計な失敗を生まない。
CMSの利用者に対して、今何が起こっているのかを簡単に確認できる仕組みを提供することは重要。いちいち挙動がおかしいと連絡を受けていては、仕事にならない。（プレビュー状態のままになっていて）現在のサイトが見れないと言われてしまう。
＊プレビューをオフにできる
＞セッションにプレビューのステートを保持しているので、これを明示的に切り替えるためのインタフェースを管理画面内に用意する必要がある。これが無いと、一度プレビュー状態になったら、セッションが切れるまで現行バージョンのサイトが見れないことになってしまう。

ローカルでDNSのキャッシュをしてみた

自宅で、HTTPリクエストのを並列処理するプログラムを書いていて、”ホストへの経路がありません”と言われてしまったので問題点を調査。リクエストを連続していると、発生頻度が上昇。どうやらDNSを引くのが追いついていない模様。というわけで、ローカルにDNSをキャッシュしてみました。
unboundっていうのを見つけたので試してみます。
使い方が非常に簡単で、動作も軽快ということなので、自宅でちょっと使うなら、ちょうど良いのかな。
起動スクリプトはないので（と、参考にしたページにありました）、rootで直接unboundを実行。
すごく無口なプログラムなので、ちゃんと起動したのかどうかも分からない。
/etc/resolv.conf を編集して対象のホストをnameserverにした状態で、digを叩くと動いているかわかります。
netstat -na | grep :53 とか、pgrep unbound とかでもOK。あ、もちろんBINDが動いてるとポートぶつかるので止めてくださいね。
で、何もしないで起動すると、失敗。動いていない様子。
unbound-control とか、 unbound-control-setup とか、unbound-checkconf とかあったので、とりあえずcheckconf してみる。
すると、サーバキーがないとかなんとか・・・。直感的に unbound-control-setup を叩いてみる。すると、/etc/unbound/ 以下に、ゴニョゴニョとキーファイルが書き出された。これで checkconf すると、OK。本当はキーファイルの管理とかもちゃんとするのだろうけど、どうせローカルホストでしか使わないから今回は省略。
で、/etc/unbound/unbound.conf があるので、これも編集。色々設定はできるようですが、
access-control: 127.0.0.0/8 allow
だけ有効にして、 resolv.conf で nameserverを　127.0.0.1 を先頭に追加し、unbound　を起動。
dig google.com
としてみる。
2回リクエストを出すと、キャッシュされているのがよく分かります。
この状態で冒頭の並行処理のプログラムを再度走らせると・・・、うむ、目に見えて早くなったじゃないか。
ただし、今度は別な問題が・・・。まぁ、TIME_WAITがたまるというやつです。
netstat -na | grep TIME_
とすると、80番ポートまわりでTIME_WAITがズラリ・・・。プログラムをそこで止まってしまいました。
これについてはまた別の機会に・・・。
速さを実現するのって難しいなぁ・・・。

ログイン情報の保持

今は何でもブラウザ上で出来るようになり、その分、様々なサービスにログインする機会も増えています。
自分はパスワードを保存したり、ログイン状態を保持するのが嫌いなので、すべてアクセスするときに再ログインし直しています。勝手にログインされるのは、たとえそのマシンを他の人が使わないとしても、気持ち悪くないですか？それに、「保持」されたセッションがどのように管理されているのか、正直不安です。まさか、クッキーにベタで生パスワードを保持しておくというようなお粗末なことは無いにしても、きちんと適切な有効期限を管理していなかったり。明示的にログアウトし忘れることはよくありますが、次回ブラウザを開いたときにそのままセッションが残っていてログイン状態になっていると、ぎょっとします。そのサービスは、パスワードを忘れると、「パスワードの再送信」みたいな機能でメールで送ってくれますが、それって生のパスワードを保持してるってことですよね。しかも、平文のメールで送りつけてる。利用者の便利さを優先みたいなことなんでしょうけど、それって怠慢だろ、と。利用者の安全を優先しないと。
で、このログイン済みの管理方法も色々あると思いますが・・・。ログイン状態を保持するっていうチェックボックスがあるのが今は一般的ですか。このチェックがデフォルトでチェック済みになっているサービスがあって、ログインするたびにこのチェックを外すというひと手間が必要になります。デフォでチェック済みは止めたほうがいいと思うな。使う人はどうせ次回は自動ログインですし。そもそも、このチェック自体、どうかとも思いますが。パスワードを保存したい人は、たいていブラウザの機能で保存しちゃったりしてます。わざわざサービス側で明示しなくても、使い慣れたブラウザのインターフェースで統一できるのだから、「蛇足」という気もするわけです。
まぁ、自分は間違ってもパスワードをブラウザに保存したりはしませんが。
あと、ログインIDを勝手に保存されるのも嫌ですね。パッと画面を開いたときに、そこにログインIDが残っているという。それはメールアドレスだったり、あるいはそのまま個人の特定に結びつくIDだったりしますから、何かの拍子にぽっと出ると、ぎょっとします。自分のPCの画面を誰かに見せながら説明したり作業したりということは、ありえるので、あまり余分なものを表示されたくはないですね。

CGI::Applicationとpsgi.input

CGI::Application::Emulate::PSGIを利用して、CGI::ApplicationでPSGIしてます。
本日、POSTされたバイナリデータを標準入力からreadしてごにょごにょするという処理を書こうとして、「あれ、STDINてどこにあるの？」と立ち止まる。
PSGIの解説を読むと、$env->{’psgi.input’}がそれに当たるとのこと。そして、CGI::Application::Emulate::PSGIの中で、
local *STDIN = $env->{’psgi.input’};
となっているので、結局特に考えることもなくSTDINを使えばいいみたい。
でも、データ読み込んでも空っぽ。どうやら、ポインタがファイルの末尾にある様子。なので、先頭までseekすればOK。
seek STDIN, 0, 0;
としたあとで読み込むと、送ったサイズと完全に一致するサイズのデータが読み取れました。
でも、ファイルの末尾までいってるってことは、すでにどこかで読み込んであるということでしょうね。もっとちゃんと調べれば、オプションとかでバッファの処理とかを指定できるのかも。あとで時間があれば、調べたい。

Hokkaido.pm#6に参加させていただきました

まずは、皆さんお疲れ様でした。遠方から参加された皆様、ありがとうございました&&お気をつけてお帰りください。
今、帰宅直後にこれを書いてます。まだ、すみれ組は並んでいるところかも？
懇親会でいい感じに酔っ払ってますので、あまりまともなことは書けません。
とりあえず、寝て起きて忘れないように備忘録的なメモをしたいと思います。
今回は関数型都市忘年会＆Hokkaido.pm合同懇親会ということで、日頃あまり触れない言語の話とかも出来て面白かったです。
Boost.Testは隙をみて試してみます。
nekokakさん。最後、短い時間でしたが、お話を聞けてよかったです。Teng使わせていただきます。
やばい、眠い。
以下、TODO
Carton触ってみますの件
Windows APIの件
mod_perlの件
C++テンプレートテクニックは買いますの件
駄目だ、眠い。
あとで読んでも何書いてるかわからないようなエントリーになってしまいましたが、とりあえず今はここまで。
とにかく、有意義な時間を過ごせました。楽しかったです。
では、寝ます。

PR-200NEとAsterisk

PR-200NE(ファームウェア Version 16.21)とAsterisk1.8を利用したひかり電話のシステムを構築していましたが、REGISTERに失敗する問題を解決できず、断念。SIPのプロトコル調べたり、パケットをキャプってみたり、色々やったのですが、ダメっぽい･･･（REGISTERリクエストを投げると有無を言わさず403 forbiddenが返ってくる）。X-Liteや３CXなどのソフトフォンからも登録不可・・・。自分の力ではここまでしか分かりませんでした。
このままでは先に進まないので、NTTに問い合わせ、PR-S300系のルータへの交換を依頼しました（過去にPR-300系ルータ+Asterisk1.8での実績あり）。通常は、客の都合での交換には応じないとのことですが、すでに案件も進行しており、システムで使用する予定の電話番号まで契約済みということで、無事に交換してもらえました（別途、工事費はかかりましたが）。
本日、その取り付け工事。で、接続テスト。
あら、なんということでしょう！今までの苦労がウソのように、簡単につながりました。
ネットで調べると、PR-200NEでもつながるということですが、若干情報が古いですね。最新のファームウェアだと無理？
とりあえず、解決したのでこれ以上は掘り下げませんが、釈然としない感じ。
もしもご存知の方がいらっしゃれば、今後のためにも教えていただきたいです。まぁ、今後PR-200NEとお付き合いすることもないとは思いますが・・・。

sudo時にaliasを引き継ぎたい

自分用に環境をカスタマイズしていると、sudoしたときにaliasがはたらかずに不便です。
ちょっとしたトリックで、これを引き継ぐようにできます。

alias sudo=’sudo ‘

これだけ。
ネタ元：https://wiki.archlinux.org/index.php/Sudo#Passing_aliases

英語を日常に

絶対に必要だと思うので、英語をコツコツ勉強しています。
でも、「勉強する」という感覚だと、なかなか長続きしません。
そこで、「日常」の中になるべく英語を取り込むようにしています。
まず、検索エンジンの言語を英語に。Facebookとかその他のツールも英語で使用。
OSも英語に（ただし、日本語もインストールしておかないと、日本語が入力などができないので）
「online manga」で検索すると、英訳された漫画がたくさん読めます。
日本語で読んだ漫画を英語でも読むと、「こうなるのか」と納得できたりしますね。
また、絵もあるので比較的理解しやすいです。
また、単語を調べるときに、英和ではなく英英で調べるのもいいかも。
調べるのに時間はかかってしまうかもしれませんが、力は付くのではないでしょうか。
いずれにしても、日常の中で習慣にできないとついついなまけてしまうので、上達しないと思います。