続・バグを生まないコーディング法 | EE Times Japan
フォーラムでの議論は次のような発言から始まった。 「中括弧を使って複合文を記述し、文の切れ目にセミコロン「;」を使う言語では、オールマン・スタイルを使うべきではない」 私はどちらのスタイルでもよいと思っているが、「1TBSでは図2のような間違いを人間のコード・レビュワーが発見しにくい」という1TBSに対する批判は受け入れがたい。 人間のコード・レビュワーが、このような間違いを見落とす可能性があることは認める。しかし、まさにこの例は、ここで紹介するようなコーディング規則の重要性を物語っている。つまり、「バグを効果的に排除するためには、コーディング規則に強制力がなければならない。2個以上の競合する規則がそれぞれバグを防げても、それらの中の1つの規則だけが自動的に強制できる場合は、より強制力がある規則の適用が推奨される」ということだ。 われわれのコーディング規則では、上記のような例はまさに自動
はてなのCAPTCHAを破るプログラムは30分で書ける - やねうらおブログ(移転しました)
CAPTCHAとは、スパムコメントなどを防止するための認証画像のことである。 それにしても、はてなのCAPTCHAはひどい。無いよりマシという考え方もあるのでそれについてはあまり議論する気は無いのだが、それにしてもこれを破るプログラムは30分あれば十分書ける。 具体的には、はてなのCAPTCHAには8つの好ましくない特徴と、2つの脆弱性がある。 ■ 8つの好ましくない特徴 ・画像自体のサイズが小さすぎる。→ こんなに小さいと探索量(計算量)が小さくて済む。 ・フォントにゆがみがない → フォントはある程度変形させたほうが良い。変形させてあるとテンプレートマッチングがしにくくなる。 ・フォントが固定。→ フォントは毎回変えたほうが良い。 ・フォントを回転させていない → フォントは文字ごとにある程度ランダムに回転させた方が良い。 ・フォントサイズが一定 → フォントサイズは文字ごとにある程度
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
