サーバにベンチを掛けて類推する（安全率、AP使用率も考慮に入れる事）

ad -n [連続アクセス数] -c [同時アクセス数] http://[アクセス先]
ab -n 1000 -c 10 http://www.bangboo.com/index.html

- Requests per second:　　23.34 [#/sec] (mean)で、一秒間に23回　→　200万アクセスまでOK
- Time per request:       50.530 [ms] 　→　140万アクセスまでOK
- Failed requests:　　　　0　→　失敗がでる同時アクセス、連続アクセスは？

・アクセス先ファイル容量
　Document Length:　　　　19670 bytes

・送信リクエスト数
　Concurrency Level:　　　10

・リクエスト完了までの所要時間
　Time taken for tests:　 50.525910 seconds

・総リクエスト数
　Complete requests:　　　1000

・取りこぼしたリクエスト数
　Failed requests:　　　　0

・1秒あたりに処理されたリクエスト数
　Requests per second:　　23.34 [#/sec] (mean)

・1秒あたりに処理された所要時間
　Time per request:　　　 515.299 [ms] (mean)

・1秒あたりに受信された容量
　Transfer rate:　　　 337.26 [Kbytes/sec] received

・上から順に接続（Connect）、処理（Processing）、待ち時間（Wait）を集計し、最小値、平均、最大値、平均で表している
　Connnection Times (ms)

・処理時間の推移
　Percentage of the requests served within a certain time (ms)

メモリ12GB搭載したSPARC SolarisのサーバでApacheのプロセスを6000個ぐらい上げた猛者もいるが、一般的なLinuxサーバでは700あたりで挙動が不安定になる。非常におおざっぱに言えば、ひとつのサーバ筐体でたかだか700人しか収容できないということ。

PHP 警告 : ページの有効期限切れ
POSTを使わなければでないのだが、IEのキャッシュがいっぱい2になったときの仕様である。

session_cache_limiter('private, must-revalidate');
かならず再読み込みをする。入力フォームで入れた情報が消える場合がある。入力値をクッキーでカバーできるならこれでOK。

session_cache_limiter('private_no_expire');
入力フォームのデータなどは消えないが必ずcacheを読むため、リロードで古いものを見せ続ける危険性がある。

&lt;a href="form.php?<?=time(); ?>">Go Form</a>
リンクをユニークにすると必ず再読み込みするようになる。

if (0 < count($_POST)) {
    session_cache_limiter('private_no_expire');
}
POSTのときだけcacheを有効にする。ブラウザの戻るボタンで戻るとPOSTできていない先頭ページは入力が消えている。

&lt;a href="form.php?doCache">Go Form</a>
if (0 < count($_POST) || array_key_exists("doCache", $_GET)) {
    session_cache_limiter('private_no_expire');
}
cacheしたいときにcache指定、POSTのときは強制cache。

--------------

■PHPのバージョンによるのか新情報

session_cache_limiterの引数は
none/nocache/private/private_no_expire/public
のいずれかしか受け付けず、その他の値をセットするとpublicを指定した場合と同じでsession_cache_limiter('private, must-revalidate')はキャッシュ制御ヘッダが送信されない

1) nocache:クライアント/プロキシのキャッシュを無効
2) public:クライアントマシン/プロキシのどちらもキャッシュ
3) private:クライアントマシンのみキャッシュ保持。Expireヘッダが送信されます
4) private_no_expire：privateと同じだがExpireヘッダはクライアントに送信されません。有効期限切れを回避

フォームの入力内容を保持して、ブラウザの戻るで戻りたい場合は、private_no_expireかnoneがいいみたいだ

●session_cache_limiter('private_no_expire');
期限切れが出にくいがキャッシュばかり使う（静的ページ、静的なページのフォーム）
※運用時はprivate_no_expireでも開発時はnoneで

●session_cache_limiter('nocache');
戻ると期限切れがでる（動的ページ、フォームには向かない）

●session_cache_limiter('none')
キャッシュヘッダを出さず、期限切れが出にくく適時読み込みをするがブラウザによる（動的なページのフォーム、更新がよく掛かる静的ページ）

●フォームに戻ってキャッシュ一杯で期限切れを出し、更新ボタンで再ポストを避けたい
期限切れを出さないフォームは、GETかsession_cache_limiter('none');かsession_cache_limiter('private_no_expire');
2重登録NGなフォームは、DBMSにPKやユニークをチェックさせるか、トークンを使うか、処理後リダイレクト

●トークン
１）フォーム表示時点で、画面にhiddenにキーを、セッションにもキーを仕込んでおく。
$taskId = mt_rand();
$_SESSION['taskId'] = $taskId;
print('<form action="submit.php" method="post">');
print('<input type="hidden" value="' . md5($taskId) . '" name="taskId" />');
print('<input type="submit" value="submit" name="submit" />');
print('</form>');
２）登録処理のとき、画面から来たキーとセッションに格納されているキーを比較して、正しくフォーム表示の画面から遷移しているか確認する。
<?php
//二重登録防止フォーム-登録処理
session_start();
$taskId = $_SESSION['taskId'];
unset($_SESSION['taskId']);
if (md5($taskId) == $_POST['taskId']) {
 print('きちんと前の画面からsubmitされています。');
 //登録処理後に完了画面にHTTPリダイレクトで遷移するようにしておけば特別な対策なしでも完了画面をリロードされても問題なし
 header(‘Location: 完了画面URL’);
} else {
 //二重登録された場合や、直接アクセスされた場合の処理
 print('フォームを通してアクセスして下さい。');
}

http://yotophoto.com/
http://www.sxc.hu/
http://www.morguefile.com/
http://www.burningwell.org/gallery2/main.php
http://davidniblack.com/imagebase/
http://www.freephotosbank.com/

<!-- This is my advice for the OLD-FASHIONED man who can NOT take resonable alternatives in mixed COMPLEX stuation. Need learn MBA not PM. PM depends on age. MBA brings everybody who wants to be in this ganeration of IT a pillar. NEXT is ... -->
スーパーのレジ打ちを顧客自身がやってはいけないのか？早く店を出ることができるようになったら、その方が顧客は喜ぶのではないか？と考える

Roger that.

mod_rewiteの設定は.htaccessに記載していることだと思うが、ヘンテコな設定はかなりApacheに負荷を掛け、Temporary Service UnavailableやForbidenなどのエラーを頻発させてしまう。

よく使われる設定は、次のようなものだ。
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^db/([0-9A-Za-z]+)_(.*)\.html$ db/db\.php?id=$1 [L]

RewriteCond %{REQUEST_FILENAME} !-d は「ディレクトリが存在しない場合」
さらに、次の RewriteCond %{REQUEST_FILENAME} !-f は「ファイルが存在しない場合」

リクエストされたディレクトリまたはファイルが存在しなければ、mod_rewiteのルール処理に行くよ。ということである。つまりルートディレクトリに置いた日には無駄にApacheのリソースを喰ってしまうのである。dbディレクトリにhtaccessを置くなど、ディレクトリ毎に設定する方策をとる必要がある。

また、ルール処理にできるだけ行かせないようにする記載方法も併せて施策としたい。

RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !\.(css|gif|jp?g|png)$
RewriteCond %{REQUEST_URI} !^/images/.*$
RewriteCond %{REQUEST_URI} !^/s/.*$
RewriteRule ^db/([0-9A-Za-z]+)_(.*)\.html$ db/db\.php?id=$1 [L]

//はじめにスケルチ
スケルチを左に回しきる、ノイズが消えるまで右へ回す

//スキップ設定
機能＋スキップ（受信しても４秒後にスキャンを再開）

//バンドサーチ
番号＋サーチ
１．航空
２．アマVHF
３．消防救急
４．小電力コードレス
５．アマUHF
６．タク
７．簡易
８．防災
９．業務
０．パーソナル

//続サーチ
▲▼/ダイヤルで続サーチ

//スキャン
スキャン（全てを小さい順にスキャン）

//特定周波数サーチ
受信（特定周波数サーチ）
発見（メータが振れる）
機能＋発見（アラーム）

違法コンテンツがサーバーにアップロードされており、他人の権利が侵害されていることを知っていた、あるいは知るに足る相当の理由がある場合、損害賠償責任を負います。それ以外の場合には，著作権者等に対して損害賠償責任を負いません。これがプロバイダ責任制限法です。

直ちに削除（あるいは送信防止措置）の対応をとっていれば、プロバイダは著作権者等に対し責任を負わないと言えます。

ただ、誰が著作権者なのか、コンテンツが違法なのかは、必ずしも明確ではないため、プロバイダ責任制限法ガイドライン等検討協議会が作成したガイドラインがあります。著作権関係信頼性確認団体からプロバイダに申し出があった場合の対処方法なども。

もちろんプロバイダ責任制限法には免責されない例外的な場合があります。サービス提供者自身が違法コンテンツの「発信者」もしくは積極的に関わる場合には免責が受けられません。

- IT法律入門
- 投稿者を特定する方法

リンクベイティング 6つのテクニック

1. 情報提供で釣る
「 X のまとめ」といった特定分野に関する包括的な情報をまとめたコンテンツを餌にする
「 X に関する n 個の効果的な方法」のような特定分野に関する How to や Know How のリストを餌にする
「 X を Y できる便利ツール」といった特定分野に関する役立つツールの紹介コンテンツを餌にする
* 国外ではホワイト・ペーパーや無料レポートをエサにするケースが多いよう。

2. ニュースで釣る
「速報！ X が Y を発表」といったように、本物のスクープを餌にする
「 X 社の Y 報道について思う」といったように、元のソース以上に釣りとしての味付けを加えてニュースを伝える
「スクープ！ X 事件の Y は Z だった」といったように、誰かの正体を暴くことや詐欺の全容を解明することを餌にする

3. 反対表明や攻撃で釣る
「 X の発言は Y の点で間違っている」のような、有名人や有名ブロガーなどの特定個人に対する反論を餌にする
「 X たちが Y するのは不快」のような、特定の集団に対する不快感を表明することによって論争を引き起こす
「 X は Y と言っているが実は Z」のように、特定の個人や集団に対する反証を上げて攻撃することで論争を引き起こす

4. ユーモアで釣る
「衝撃！まるで X のような Y 画像」のような形で、flickr などで見つけてきた面白い画像を餌にする
「 X が Y する決定的瞬間」のような形で、YouTube などで見つけてきた面白い動画を餌にする
「 X とかけて Y と解く。その心は？」や、
「 X なのに Y とはこれいかに？」のような定番を使って小咄を作り、餌にする。

5. 煽りによって釣る
「あなたが考えているほど X は Yではない」や、
「勘違いするな！ X は Y ではない」や、
「 X は本当に Yか？」や、
「 X も絶賛、今流行の Y の秘密に迫る」など、女性週刊誌や午後のワイドショーのような煽りを餌にする
「 X な人が陥りがちな Y の落とし穴」のように、男性誌にありがちな煽りを餌にする
「知らないと損する！ X に関する n 個の知識」のような形で、相手の無知に対する危機感を煽る
「 X は Y ですが何か？」や、
「はいはい X を Y した俺が来ましたよ」や、
「 X の Y が激しく Z すぎる件」に代表されるようなものも日本のネットコミュニティにおいては見られる

6. レビューで釣る
「 X の新製品 Y のここが凄い」といったように、話題の製品について変化をつけた視点からのレビューで釣る
「あの新名所 X に行ってきました」のように、話題の場所やサービスの流行に便乗する形のレビューで釣る
「話題の X に潜む危険すぎる Y 」といったように、話題の製品やサービスについての批判的な側面からのレビューで釣る

警察からの（情報開示など）捜査依頼が来た時マニュアル

1) 本物の警察かどうか
警察の番号は下4桁が「0110」になるのがルール、電話番号を聞きこちらからかけ直す。

2) 投稿の削除依頼
拒否しても構わない。警察からの削除依頼だからといって無条件で削除する義務はない。内容が正当だと思ったものに関しては削除できない旨を伝える。

3) 投稿者の個人情報の開示
- そのままメールや電話で開示する
- 捜査関係事項照会書を送ってもらい文書で開示する
- 裁判所からの令状があり次第開示する

基本的に、警察からの開示請求の段階では義務はない。あくまで「お願い」の状態だからである。一番リスクが少ないのが裁判所からの令状があり次第開示するというものですが、余計な手間を避けるため「捜査関係事項照会書を送ってくれ」と伝えて送ってきたものに関して文書で開示する方法が妥当か。メールや電話で開示しても、プロバイダ責任制限法案があるので、責任が問われることはほぼない。

伝えるべき内容は以下。「こちらでは投稿者の発信者情報しか取得しておらず、それしか開示できません。その情報を持って、プロバイダに開示請求をしてださい。」

4) 警察対応の注意点
警察への対応の一番の注意点は、警察は「判断者」ではない、ということです。警察の要求に応えて行動したからといって、その行動が正当なものであるかどうかは保証されません。その行動について責任を問われる可能性もあります。（警察が「人を殺せ」といったから殺した、という理由が通らないのと同じ）


///メディアトレーニング
http://www.bangboo.com/media/

WEBブラウザの仕組みとして、まず第一にクライアントからのアクションがなければブラウザにデータが送られることはなかった。しかし、この課題を解消する方法として、非同期通信を採用したのがAjaxである。だがAjaxにしても、定期的に問い合わせ（ポーリング）しなければならなかった。現在もっともリアルタイムにプッシュ通信させる方法として"Comet"がある。WebクライアントからのHTTP要求に対して、すぐには返答を返さず、メッセージの追加などサーバサイドでのアクションをトリガーにして返答するというものだ。

- Lingr API