「アカウントのロックアウト」とは、
ユーザアカウントを凍結して、ログインできないようにすること。

パスワードを闇雲に試してみようとする輩を排除するために、
一定回数以上パスワードを間違えると、
自動的にそのアカウント(ログインID)が使えなくしたりする。

ただし、第三者がログインIDを知っている場合、そのアカウントになりすまして
わざと誤ったパスワードを何回も入力し、アカウントをロックアウトしてしまうという
嫌がらせができてしまうわけだ。

銀行ATMでも同様の機能があるが、ログインIDにあたるのがキャッシュカードであり
これは容易に他人の手に渡らないので大丈夫。
でも、ログインIDとなるとそこまでのセキュリティ感覚は働きづらい。

この点を考慮せず(甘く見て)、その復旧を管理者の手動とかに設計すると
年中無休即時対応のサポート並みに地獄をみることになる…かも。

だから、回復方法としては、一定時間おいたら自動的に復旧させる、
当事者にアカウントがロックした旨のメールを出して自分で復旧してもらう、
とか自動化が必要だ。

あ、そうそう、「アカウントのロックアウト」には
迷惑行為をする輩を締め出すためって場合もある。
ま、これは懲罰処置だから、ロックアウトしちまえば終わり。
あと、これこれこういう理由でロックアウトしたよって通知すれば親切だね。

単勝一番人気は「オッズが最小のもの」ではない。
一票も得票がない「0倍」が一番人気になってしまう危険性がある。

よって、「オッズが0倍を除く最小のもの」としなければならない。

「得票数が最大のもの」だと安全なのだが、
たいていはオッズの方のみが公開されてるものだ。

何らかの文書を編集後、「保存」を実行し、データを保存する。
「保存」を実行せずに終了すると、データは保存されない。

これは、(処理速度の速い一時記憶装置へ逐次記録して)
処理速度の遅い永久記憶装置への書き込み回数を極力少なくしようという
制約から来ているのだと思うが
もうコンピュータ操作のルールとして広く浸透している感がある。

当然ながら、現実社会では(紙に)書いた瞬間に保存される。
「保存」処理を行ってからノートを閉じるなんてことはしない。

でも、前者のルールに慣れてしまえば、逐次保存処理が行われたりすると
勝手にデータを破壊されるようで危なっかしくてかなわない。
＃そんなダンプツールをいじるときは冷や冷やする。

現実社会と同様の処理の流れとすれば操作性としては感覚的にわかりやすいが
必ずしもそれが便利だとは限らず、
コンピュータ世界の(大多数の)流儀に従ったシステムの方が
(他で慣れているので)逆に感覚的にわかりやすい場合もある。

ただし、コンピュータ世界のローカルルールを押しつけるというのは
如何なものかというのものある。

例えば、現実社会と同じように逐次記録するけど、
UNDO機能というやり直し機能が精巧に出来ていて、やり直しが効く、
保存していない状態に戻れるというのであれば、両者のいいとこ取りのような感じだ。

ただし、それでも「保存」処理に慣れてしまっていれば、
UNDOすらめんどくさいとなる。

生まれながらにそのシステムに慣れてしまえばそれが正義になるのだろう。

「1年1組」と「2年1組」は別のクラスだ。

「1組」という名称が同じでもだ。

「年」＋「組」で一意だからだ。

ただ、「1年11組」と「2年21組」としてしまえば(1学年が9組以下という前提で)
組だけで一意に判別することができる。

「11組」は学校に一つだけの組だからだ。

ってなると、「年」って何の意味があるの？ってことになる。

データベースの世界で、枝番を自動採番する主キーにすればこれと同じことが起きる。

でも、便利なことは便利だ。
いちいち二つ以上のキーで連結しなくてもよい。

枝番はなにもきっちり前詰めじゃなくてよく、スペースを大きく使ってよいってことなら
これもアリかもしれない。

入力エラーチェックは入力直後のクライアント側におけるチェックと
データベース等に書き込む直前のサーバ側におけるチェックがある。

前者はJavaScript、後者はPHP等による処理ということになろう。

後者の方がより書き込む処理に近いので安全であるといえる。

しかし、UIの観点からは前者の方がやさしい。
入力した内容が誤っていてもそのまま画面に残っているからだ。

後者であっても、入力した内容を引き継げばそれは実現できるのだが
ちょっと煩雑な気がする。

もちろん前者だけではチェックに限界がある場合がある。
例えば、画面に表示されていない情報をデータベースに問い合わせなければ
ならない場合などは、通常のJavaScriptでは無理だ。

しかし、Ajaxを使えばそれは克服できそうだ。

ドリー・ファンク・ジュニアの父は、ドリー・ファンク・シニアだが、
ムーミンパパの子供はムーミン子ではなく、ムーミンだ。

両者は基点違うのだろう。

前者は父と子の間に、見えない基点があって、そこからの距離で決まっている。
「-1」(子)と「1」(父)の間に「0」がある感じだ。

一方、後者はあくまで基点は子で、「1」(父)と「0」(本人)の関係だ。

結構これがごっちゃになるケースというのはあるので注意が必要だ。
＃「0」オリジン、「1」オリジンの違いとも似ている。

設計に限った話ではないが、パソコンで書く文章に句点(「。」)は必要なのだろうか？

日本語としては当然「。」があった方がいいのだろう。
そういう常識から、「。」がないことを画一的に批判する人もいる。

でも、読みやすさとしては、「。」で改行した方が断然見やすい。

ってことは、末尾の「。」って別になくてもいいじゃんと思う。

実際、禁則処理なんか気にせず「。」を改行コード(\n)に置換しちゃえば楽チン。

別に「。」の後に空改行をいれなくても全然違和感はない。

ま、最大の欠点は、一行に二文以上書けないということなんだけどね。

ここだけ、「。」で区切るってのもね(だいたい、「。」は全部置換するつもりだし)。

ってことで、当ブログでは一行に二文以上書きそうなので、
他の文書とは違って「。」を使ってます(ダブルスタンダードは避けては通れない)。

パスワードってのは他人に知られてはいけない。
だから暗号化する。

「A(暗号化前)→B(暗号化後)」を例として話を進めると。

「A」を管理するのは危険だ。
もし管理者が会員全員のパスワードをすべて持っているとしたら
それを覗かれた場合大変なことになるので、かなり神経を使うことになるだろう。

暗号には復号がつきものだ。
でも、パスワードの場合は復号の必要はない。
パスワードが一致すればそれで事足りるのだ。
もし、パスワードを忘れてしまったら？
元のパスワードなんか教えなくたっていい。
再発行すればいいのだ(そして再設定してもらう)
＃そもそも忘れるようなパスワードを教えてもらってもまた忘れるかもね

とにかく「A→B」の矢印は「A←B」である必要はない。

ってことで、「→」しか方向がない強力な暗号化機構を用意して
・パスワードは「B」のみを管理して「A」は入力した時だけ使って破棄する
・パスワードの照合(一致)は「→」を使って変換した「B」(？)が
  管理(保持)している「B」と一致するかで判定するようにする
っていうルールにすればよい。

これだと例え「B」が流出しても「→」を使って変換した結果を照合するので
「B→Z」とかになって「B」だけでは役立たずになる。
「?→B」となる「?」がわからなければ意味がない。
そしてそれは「←」がないので事実上無理。
これで、管理者は結構楽になる。

さて「→」にあたる機構、どんなのがあるのか？
ハッシュってのがあって、「md5」とかいろいろ種類がある。
こいつの特徴は「B」が固定した幅の値に収まる。
つまりどんなAであっても、Bは「00～99」になるみたいなもんだ(1でも1000でも)。
ってことは、重複もありうる。
そう、「A」でも「C」でも「→B」となる場合がありうるのだ。
でもこの確率はとっても低いらしい。
(Bの幅が十分に広くて、Aも使えない文字とかもあって入力が限られるから)
そしてなによりも「AorC→B」ってことは、「←」が難しいことが一目瞭然。
(な気がする)

「2」と「10」の場合、数値としてソート(昇順で)すると「2→10」の順になるが、
文字列としてソートすると「10→2」の順になる。
文字列だと先頭の一文字目で「1」と「2」を比較して「1」が先に来るからだ。
「い」と「ああ」をソートすると「ああ→い」の順になるのと同じだ。

特に「文字列＋数値＝文字列」の場合に顕著になる。
「番号2」「番号10」とかの場合。(「番号10」が先になってしまう)

回避方法とは？

ま、ゼロパディングでしょうなぁ。
「番号02」「番号10」にすりゃ問題なし。

「02」ってのが嫌なら「番号②」「番号⑩」って方法もある
でも「⑳」までしかないけどね。(それに特殊文字はちょっと)

ま、後は、表示用項目とソート用項目とを分けて
ソート用項目は「番号02」、表示用項目は「番号2」とか二重管理してしまうのも手だ。
どうせだったら、ソート用項目を順番の連番にしてしまうってものもあり。
これをIDと言ったり言わなかったり。

ゼロパディングたって何桁パディングすりゃいいんだかってのも結構重要。
さっきの例だと「100」を超えて3桁に突入したら破綻する。
まるで二千年問題だね。
でも大抵は、数値項目でもあらかじめ桁数を決めたりするものなので、
そんなに悩まなかったりするかも。

┌──────────────────────────────────────┐
│Ｑ．ボタンの並び順はどっちがいい？                                          │
│    (a) 「OK／キャンセル」の順                                              │
│    (b) 「キャンセル／OK」の順                                              │
└──────────────────────────────────────┘
  Ａ．甲乙つけがたし。
    (a) ・Windows派(Windows環境の標準)
        ・「はい／いいえ」と同じ並び(重要な方が先にくる)
    (b) ・Mac派(Mac環境の標準)
        ・「←戻る／進む→」と同じ並び

基本の流れはあくまでも画面左上から画面右下へ。
よって、「OK」ボタンは画面右下におくのがセオリー。(画面下中央もギリギリOK)

ただし、この周囲に「キャンセル」ボタンをどう置くか？

画面右下の中で、その中でも右に「OK」を置くのが流れ的にはいい感じがする((b)派)。
┌──────────────────────────────────────┐
│                                                  ┌─────┬─────┐│
│                                                  │キャンセル│    OK    ││
│                                                  └─────┴─────┘│
└──────────────────────────────────────┘

しかし、画面右下の中でもその下に「OK」を置くのはちょっと違和感がある。
┌──────────────────────────────────────┐
│                                                              ┌─────┐│
│                                                              │キャンセル││
│                                                              ├─────┤│
│                                                              │    OK    ││
│                                                              └─────┘│
└──────────────────────────────────────┘

やっぱり、こっちだよね。
┌──────────────────────────────────────┐
│                                                              ┌─────┐│
│                                                              │    OK    ││
│                                                              ├─────┤│
│                                                              │キャンセル││
│                                                              └─────┘│
└──────────────────────────────────────┘

「Yes-No枕」はあっても、「No-Yes枕」はない。

日本人だって「はい、いいえをはっきりしなさい！」であって
「いいえ、はいをはっきりしなさい！」とはあんまり言わない。

ってことは、画面右下というブロックの中で「OK」は先(左)にあってよい((a)派)。
┌──────────────────────────────────────┐
│                                                  ┌─────┬─────┐│
│                                                  │    OK    │キャンセル││
│                                                  └─────┴─────┘│
└──────────────────────────────────────┘

でもでも、画面右下とはいえ「進む→／←戻る」ってのはねえ。
＃あれ？この書き方だと結構イケてるデザインに見えなくもない(笑)

要は、慣れ、そしてデファクトスタンダードが決め手ってことか。
パソコンの世界ではWindowsが王者なので(a)が優勢、
Webの世界では、IEだって履歴ボタンは「←・→」だから(b)が優勢って感じなのかも。

自分が作成当事者だった場合は、
自分が掌握(作成)するそのシステムの小さな世界において
どっちかに統一されていればいいって結論なんだろうけどね。
＃んなこといったって、外の世界で二大勢力が拮抗していると
  谷間のラーメン屋としてはどっちにつくべきか風見鶏なわけです