無精で短気で傲慢なプログラマ

UNIX や web やプログラムの技術的なことを中心に。

find には sh!

ウノウラボ Unoh Labs: コマンドラインで作業する上で知っておくといいテクニック
% find . -name '*~' -exec rm {} \;

404 Blog Not Found:勝手に添削 - find(1)
% find . -type f -name '*~' | xargs rm
% find . -type f -name '*~' | perl -nle unlink

わたしなら
% find . -type f -name '*~' | sed 's/^/rm /'
で確認し、OK なら
% find . -type f -name '*~' | sed 's/^/rm /' | sh
で消します。

いまどき fork/exec rm のオーバーヘッドがどれほどのものか。
xargs を使うとき、rm が 1回だけ実行されるときと、ARG_MAX を超えたときに
rm が複数回実行されるときの違いにどれほどの差があると言うのか。
誤差の範囲である。

コンピュータが速くなった今、重視すべきは確実性。
% find . -type f -name '*~' | sed 's/^/rm /'
として、
rm ./hoge~
rm ./dir/fuga~
rm ./foo/bar/baz~

という出力をじっくり眺め、問題がないことを確認する。OK なら、最後に "| sh" をつけて
% find . -type f -name '*~' | sed 's/^/rm /' | sh

とする。

削除してマズいファイルを見つけたら、grep -v で除外すればよい。

find コマンドは、人が使うには難しすぎる。なんだよ {} \; って。
xargs コマンド は、何をするコマンドなのかさえ直感的にわかりづらい。
わざわざ難しいことをする必要はないではないか。

単純なファイル削除ではあまり利点が見えないかもしれないが、便利なのは例えば
% find . -name \*.html | sed "s|\(.*\)|command < \1 > out/\1 | "
などというとき。出力が
command < hoge.html > out/hoge.html
となっていることをじっくり確認して、最後に "| sh" を付けて実行する。

何が起こるかは出力をじっくり観察すればわかる。見よ、この安心感。


…ってちょっと無理があるか? sed の基礎はおさえておかなきゃいけないし、
メタキャラクタ入りのファイルに弱いしなぁ。

sh をつけるやり方を流行らせたいんだが、無理かなー。いやほんと、便利よ。
最初の数行だけ試しに実行したかったら出力をマウスでコピペすればいいし、
コマンドラインだけでがんばるのが厳しかったら、ファイルにリダイレクトして
エディタで中身をいじって
% sh < command.txt
としてもいい。


ちなみに環境により挙動が異なる echo(1) は使わず、printf(1) を使うのが
POSIX 的な解かと思います。といっても、まわりの人が全然知らないので
仕事ではあえて使わないけど。

スポンサーサイト

PageTop

web 開発のヒアリングシート/チェック項目

要件定義のヒアリングシートはいくつか見たことはあるが、web 開発に
特化したまともなヒアリングシートを見たことがないので作ってみた。
「サイトの目的は」などの上流部分はあえて省いて、機能・実装にフォーカスしている。

思いつくままに記述してみたが、結果としてはインターネット上の
コマース向けサイトに特化した形になった。

請負時のヒアリングシートと、発注時の要件伝達漏れチェックシートと、
開発時のレビュー観点の元ネタとして使えるといいなぁ。今後気づいた
ところがあれば追記していきます。

●2010/02/24 追加分。
- サイトメンテナンス時のアナウンス要否
  - メンテナンスページは「503 Service Temporarily Unavailable」を返すようにし、
   検索エンジンにキャッシュされないよう注意する。

●2007/08/23 追加分。
404/403/500 などのエラーページについて
  - できる限り ErrorDocument 404 http://example.com/error404.html などの絶対 URL
   ではなく、ErrorDocument 404 /error404.html と相対 URL で書く。
   参考: ErrorDocumentを絶対URLで書くのはやめようよ

●2007/07/22 追加分。
入力フォームについて。
 - 半角のみ・全角のみの場合は、ime-mode の active/inactive を設定する。disabled は
  設定しないことをおすすめする (メールアドレスを disabled にしてしまい
  日本語ドメインが入力できなくなる、といった事態は避けたい)。現時点
  では IE6/IE7 のみ。Firefox はバージョン3で対応予定 →参考

●2007/05/01 追加分。
  - ファイル一覧・CVS ディレクトリ・.htaccess・.htpasswd など、見えてはいけないファイルの隠蔽
    - ファイル一覧が見えてしまうようなら、とりあえず Options -Indexes。
    - さらに DirectoryIndex ディレクティブを適切に設定する。
    - CVS/ などの管理用ディレクトリは DirectoryMatch などで deny。
    - .ht から始まるファイルは、apache のデフォルト設定で <Files ~ "^\.ht"> されているので
     問題ないはずだが、誤って見えてしまっているサイトが結構ある。

●2007/04/22 追加分。
  - http://www.exmaple.com と http://exmaple.com のどちらが正式 URL かを明確に決める
   - いずれにしても、www あり・なしの両方でアクセス可能なようにする
   - たとえば www ありが正式な URL なら、www なしの方は www ありにリダイレクトする
   - URL をうろおぼえで入力する人や、印刷された URL を入力する際にwww 有無を
    間違えることは結構ある。間違った URL でも、とにかくサイトにたどりつける
    ようにはしておく。
   - www あり・www なしの両方でサイトが閲覧できるようにはしないこと。両方とも
    検索エンジンに拾われると、集客が分散してしまう。必ず片方はリダイレクトする。


----------- ここから ------------
●コンテンツ
- サイト内検索有無
- ランキング系コンテンツの有無
  - ランキング生成ロジックは?
  - リアルタイムに生成? バッチで生成?
  - 管理者がランキングを自由に設定できる必要あり?
- 画像・アイコン有無
  - flash の有無
  - マウスオーバー用の画像要否
  - img 要素の width/height 属性を付ける
   - 多種多様な画像サイズが存在し、なおかつ自動で更新されるような場合、
    width/height を事前に調べるバッチの要否を検討
  - 携帯端末用画像ファイル生成が必要か?
    - 端末ごとに、フォーマット・画像サイズに制限がある
  - favicon.ico
    - IE7 のタブに favicon が表示されるので、忘れずに作成したいところ。
- ヘッダ・フッタ有無/種類数
  - ヘッダ・フッタを表示しない例外ページはないか?
- RSS の有無
- 会員規約/利用規約の有無
- 会社概要の有無
- サイトマップの有無

●Web ポリシー
- 想定の回線速度
- 対象ブラウザ
  - IE6/IE7/Mozilla/Firefox/Safari/Opera/...
- Javascript 必須でよいか?
- cookie 必須でよいか?
- Javascript/cookie を解さないブラウザがきた場合、入り口ではじくべきか?
- 想定の画面解像度
  - ブラウザ左のツールバー・エクスプローラバーの存在を忘れずに
  - 画面横幅固定? 可変? 範囲指定? (max-width、min-width)
  - 画面横幅固定の場合、センタリング?
- web エンコーディング
  - 個人的には EUC-JP だが、使用したい文字によっては UTF-8 もあり。
  - 携帯なら実質 Shift_JIS
- 長い文字列 (ユーザが長い文字列や URL を入力した場合の対応)
  - Firefox はブロック要素を突き破ってレンダリングしてしまう (CSS の
   規格としては誤りではないが、これが原因でデザインが大崩れしたりして
   よくモメる)
   - 対策その1: css で word-break: break-all; overflow: hidden
    (Firefox では長い部分が隠れる。overflow: auto でスクロール
     バーを出すのもアリだろう)
   - 対策その2: 一定文字数ごとに、wbr 要素・ソフトハイフン (&shy;) の挿入
   - 参考: 長い文字列の改行方法 - wbr, &shy;, css
   - 参考: Firefox 3 の修正内容のご紹介 その3 ― URLも改行されるように
- リンクポリシー
  - 外部サイトに飛ぶ場合は target="_blank" とする? 同一ウィンドウに表示する?
- ポップアップ
  - ポップアップを実装する場合、ブラウザのポップアップブロック機能に邪魔
   されないよう気をつける (必然性のある場合のみ実装しよう)
  - ボタン押下でポップアップ表示 → ポップアップのウィンドウが背面に隠れる →
   再度ボタン押下、とした際、最前面に表示されるようウィンドウを focus() すること。
- 404/403/500 などのエラーページのカスタマイズ要否
  - できる限り ErrorDocument 404 http://example.com/error404.html などの絶対 URL
   ではなく、ErrorDocument 404 /error404.html と相対 URL で書く。
   参考: ErrorDocumentを絶対URLで書くのはやめようよ
- 機種依存文字の有無
- 携帯の場合、絵文字の有無 (キャリアごとに互換性がまったくなく、一から実装すると
 かなりしんどい。絵文字ライブラリの購入も検討するとよい)
- Google Analytics 設定要否
  - SSL の場合は https の方を読むよう注意
- Google Sitemap 設定要否

●入力フォーム
- 入力補完
  - 全角半角自動変換
  - 前後の空白・タブの自動除去 (メーラー・Excel からコピペした場合によく空白がつく)
- エラー時の挙動
  - Javascript によるチェック要否
  - エラー表示方法
    - 画面上部にまとめてエラー内容を表示する?
    - 各 INPUT 要素の上下にエラー内容を表示する?
- submit ボタン連続押下対策要否
  - うっかり連打した場合を考えると、2回目の処理がエラーとなり、
   「エラーです」と表示されるのはよろしくない。
- 固定幅フォント
  - メールアドレス入力フォームなどは font-family: monospace で固定幅フォントにする
   (カンマとドットを判別できない人が多いため)
- 半角のみ・全角のみの場合は、ime-mode の active/inactive を設定する。disabled は
 設定しないことをおすすめする (メールアドレスを disabled にしてしまい日本語ドメイン
 が入力できなくなる、といった事態は避けたい)。現時点では IE6/IE7 のみ。Firefox は
 バージョン3で対応予定 →参考
- モバイルの場合、input 要素に istyle, mode, format 属性を指定
 することで全角かな/半角カナ/英字/数字が指定可能。→参考
- input 要素の maxlength は指定しない
- チェックボックス・ラジオボタンには label 要素必須 (わたしの趣味)
- TEXTAREA には wrap="off" 必須 (わたしの趣味)

●メール
- メール送信有無
- 携帯にも配信するか?
  - キャリアに SPAM 判定されないための対策が必要。
    - 適宜 sleep を入れる?
    - 高速配信エンジンを利用する?
- エラーメール対処
  - エラーメールが返ってきたら、どうする?
    - ヘッダに X-HOGEHOGE-ID: などと独自ヘッダを付け、/etc/aliases 経由で
     エラーメールの X-HOGEHOGE-ID を解析するのが好き。
  - エラーメールを管理者がチェックする必要があるか?
- メールアドレス形式チェック
  - 携帯の場合、「顔文字@docomo.ne.jp」などのメールアドレスが平気で
   使用されるので、あまり厳密にチェックしない方がよい。
  - 携帯の場合、「.hoge@example.com」など RFC 違反のメールアドレスが
   利用可能なため、あまり厳密にチェックしない方がよい。
  - Postfix はデフォルトではハイフンから始まるメールアドレス宛に
   送信しないことに注意 (RFC 的にはハイフンで始まっても問題ない)。
   allow_min_user=yes で送信可能。
- メールのエンコーディング
  - ISO-2022-JP が無難だが、半角カナを含む場合は要検討
  - UTF-8 で送る場合は、配信先メーラーの対応状況をチェック
- メールマガジン有無
  - ユーザごとに異なる文面のメールを送る?
    - 冒頭に「○○さん」と顧客名を出す?
    - リンク押下を追跡できるよう、メール中の URL に一意なパラメータをつける?
  - 配送予約要否 (n日の AM 9:00 から送信開始、など)
  - 夜間配送 OK?
    - 携帯電話の場合、夜間のメール送信はクレームにつながる
- 1行あたりの文字数
  - sendmail だと確か 1000バイトで強制的に改行を入れるはず
  - 1行が長い CSV ファイルなどをメールでそのまま送る場合は注意

●CGM
- CGM の有無 (Consumer Generated Media: ユーザ参加型コンテンツ)
- 管理者による投稿内容チェックが必要か?
  - 事前チェック? 事後チェック?
  - ユーザからの通報機能は必要?
  - ブラックリスト方式による自動通報機能は必要?
- ユーザへの警告通知/投稿禁止/強制退会機能の有無

●SEO・SEM
- TITLE 要素
- META タグ
  - keywords 有無、動的/静的
  - description 有無、動的/静的
- URL 静的化 (foo?a=b&c=d ではなく foo/b/d とする、など)
- ALT 要素
- URL にキーワードを含める?
 (Amazon のように、商品名を URL エンコードして URL に埋めたりする?)
- モバイル検索に対応する?
  - DoCoMo と au が検索サービスを開始した。モバイルの検索は、今かなりアツい。

●アナウンス
- アナウンスは必要?
  - トップページのみ? 全ページに表示する?
- サイトメンテナンス時のアナウンス要否
  - 「現在メンテナンス中です」と表示するために、別マシンや別 web サーバを
   用意する必要がある?
  - メンテナンスページは「503 Service Temporarily Unavailable」を返すようにし、
   検索エンジンにキャッシュされないよう注意する。

●業務系
- ユーザ種別 (一般/会員/特別会員/代理店/管理者/スーパーユーザなど)
  - 何種類?
  - 役割は?
- 利用する場所は? (自宅/社内/営業所/出張先/取引先)
- 認証有無
  - パスワード忘れの場合は? リマインダ?
  - BASIC/Digest 認証?
  - セッション用 cookie 発行?
  - ルータによる IP アドレス制限?
- 承認フローが必要な部分は? (上司が承認ボタンを押さないと公開されないなど)
- マスタは?
  - どんな種類のマスタがある?
    - 部門マスタ/取引先マスタ/担当者マスタ
    - 商品マスタ/在庫マスタ
    - 郵便番号マスタ
    - 銀行マスタ (金融機関コードなど)
    - 営業日マスタ
    - 商品区分マスタ
    - 消費税マスタ
    - 和暦マスタ
  - マスタは初期設定のみでよい? 自動流通? 管理画面から参照/編集可能?
- Excel・Word・PowerPoint ファイルを生成する必要は?

●広告
- 広告有無 (サイトを広告媒体化する?)
- 予約機能有無 (n日の 0:00 から表示開始、など)
- 会員登録時に、ユーザの属性 (性別/年代/都道府県など) を尋ねておく必要あり?
- ページごとに、表示する広告を変えたい?
- ユーザの属性ごとに表示する広告を変えたい?
- PC/モバイルごとに表示する広告を変えたい?
- ランダム表示あり?
- テキスト広告? 画像広告? flash 広告?
- 表示条件は、期間設定? 表示回数? クリック回数?
- レポート機能有無
  - CSV を吐き、Excel で整形してもらう?

●ログ・監視系
- アプリ出力のログ内容は?
  - エラー発生時?
  - バッチの開始/終了メッセージは?
    - 開始/終了の際は、日時と「開始しました」「終了しました」をログに
     残そう。実行されていたという記録になるし、実行時間の計測もできる。
  - 管理者の操作を記録する?
- ログローテート方針は? 年月日付きのファイル名に出力する?
- ログのフォーマットをかっちり決めてしまおう。おすすめは↓ (grep したときに
 わかりやすいように作る)
  YYYY/MM/DD HH:MM:SS プログラム名(プロセスID) ステータス ログ内容
  例:
  2007/03/29 03:52:34 mailsend.pl(7223) INFO 開始しました
  2007/03/29 03:52:35 mailsend.pl(7223) INFO 商品発送メール送信。会員ID[2422] オーダID[39273]
  2007/03/29 03:52:35 mailsend.pl(7223) ERROR 発送状態ステータス異常。送信スキップ。会員ID[4522] オーダID[32324] ステータス[3]
  2007/03/29 03:52:36 mailsend.pl(7223) INFO 終了しました
- 保存期間は?
- 保存対象は?
  - アプリ出力のログ
  - SMTP サーバ等ミドルウェア出力のログ
  - OS 出力のログ
- ディスク容量監視/自動通知
- 負荷監視/自動通知

●インフラ/システム
- 自社内サーバ? ハウジング? レンタルサーバ? 共用サーバ?
- DB 有無
  - レプリケーション有無
  - トランザクションログ有無
- SSL 有無
  - 携帯端末の場合は対応認証局が少ないため、ベリサインにしておくのが無難
  - SSL から非 SSL ページの画像や CSS・Javascript などを呼ぶと、IE は警告が出る
   (共通ヘッダなどで src="http://example.com/common.css" などと書き、SSL
    ページからそのヘッダを使用すると警告のダイアログが表示される)
- RAID 有無
- バックアップ
  - タイミング (日次/週次/月次/年次)
  - 対象
    - プログラム
    - データファイル (自動生成される CSV など)
    - DB (フルダンプ/トランザクションログ)
  - バックアップ先 (自サーバ内/他サーバ/テープ)
- ドメイン取得有無
- サブドメイン設定有無
  - cookie 対応
- DNS 設定有無
  - http://www.exmaple.com と http://exmaple.com のどちらが正式 URL かを明確に決める
   - いずれにしても、www あり・なしの両方でアクセス可能なようにする
   - たとえば www ありが正式な URL なら、www なしの方は www ありにリダイレクトする
   - URL をうろおぼえで入力する人や、印刷された URL を入力する際にwww 有無を
    間違えることは結構ある。間違った URL でも、とにかくサイトにたどりつける
    ようにはしておく。
   - www あり・www なしの両方でサイトが閲覧できるようにはしないこと。両方とも
    検索エンジンに拾われると、集客が分散してしまう。必ず片方はリダイレクトする。
  - MX 設定
  - au 宛に送信したメールについて、エラーメールを受け取りたい場合は SPF 対応が必要
- 開発環境・テスト環境の有無
  - 開発環境・テスト環境・本番環境の 3本立てが望ましい (DB も別)

●セキュリティ
- XSS
  - 表示の際に、実体参照化すること
  - 実体参照化する文字は < > ' " &
  - あらゆる箇所で実体参照化するのを忘れずに。
    - input 要素の value 属性内、a 要素の href 属性内、javascript 内、
     title 要素、meta タグなどは、実体参照を忘れがち。
    - href="hoge?a=b&c=d" は誤り。href="hoge?a=b&amp;c=d" が正しい。
- SQL インジェクション
  - あらゆる箇所でバインドを使う
- コマンドインジェクション
  - sh を実行させない
- セッション固定化 (Session Fixation)
- CSRF
- パストラバーサル (ファイル名をパラメータで受けてしまい、../../data/hoge.csv などが
  漏洩してしまう
  - そもそもファイル名をパラメータで受けない。ファイル ID などを受け取り、
   ファイルID を元にファイル名を決定するようにする
- ドキュメントルート以下に、できるだけデータファイルを置かない
- 事前に漏れては困るコンテンツがあるか (URL が推測可能になっており、
  入試結果発表データなどが漏洩してしまわないか)
- サーバ内にアンチウィルスソフトが必要か
- DB などのパスワード
  - ソースファイルに直接記述しない
   (.htaccess などの設定ミスでソースが丸見えになっても大丈夫なようにする)
  - 設定ファイル化したとしても、ドキュメントルート以下に置かない
   (誤って Options +Indexes とした場合、設定ファイルを発見されてしまう)
- apache のバージョン隠蔽 (ServerTokens と ServerSignature の設定)
  - 個人的にはどうでもいいと思っているが、脆弱性診断などでは指摘されて
   しまうので。
- apache のマニュアルページ
  - http://example.com/manual/ で apache のマニュアルが見えてしまうと、
   ちょっと恥ずかしい。DocumentRoot は必ず /home/service/www/ などに
   変更しよう。
- ファイル一覧・CVS ディレクトリ・.htaccess・.htpasswd など、見えてはいけないファイルの隠蔽
  - ファイル一覧が見えてしまうようなら、とりあえず Options -Indexes。
  - さらに DirectoryIndex ディレクティブを適切に設定する。
  - CVS/ などの管理用ディレクトリは DirectoryMatch などで deny。
  - .ht から始まるファイルは、apache のデフォルト設定で <Files ~ "^\.ht"> されているので
   問題ないはずだが、誤って見えてしまっているサイトが結構ある。
PageTop