パスワード議論2(世代管理について)
前回はパスワード登録・変更等におけるエラーチェックに関していろいろ個人的な見解を述べたが、
少し違う方針の「エラーチェック」にパスワードの世代管理の考え方が存在する。
要するに”変更しようとしたパスワードは昔使ったことあるから変更できないよ”というやつである。
管理が何世代に及ぶかにもよるが、個人的にはこれも鬱陶しい仕様の一つになっている。
前回はパスワード登録・変更等におけるエラーチェックに関していろいろ個人的な見解を述べたが、
少し違う方針の「エラーチェック」にパスワードの世代管理の考え方が存在する。
要するに”変更しようとしたパスワードは昔使ったことあるから変更できないよ”というやつである。
管理が何世代に及ぶかにもよるが、個人的にはこれも鬱陶しい仕様の一つになっている。
仕事で担当しているのは基本的に業務システムがメインだが、
いくつかの例外を除いていずれも「ログイン画面」が存在していて
ユーザー名(ユーザーID)とパスワードを入力してシステムにログインしてから業務を行うタイプのものがほとんどだ。
担当してきた業務システムを見るに、この「パスワード」に関してはシステムによって様々な考え方が存在するらしい。
javaにはオブジェクトの内容をそのままファイルにして出力したり、そのファイルを読み込んでオブジェクトとして復帰させる方法が存在する。
Serializableというインターフェースを実装することでそれが可能になる。
ある目的のために少し勉強したことがあるので、簡単な実現方法と共にここにメモ書きを残す。
火山が大規模噴火する夢を見た。
結構恐ろしい夢だった。
最近長男(3歳)がトッキュウジャーにハマっている。
マックのハッピーセットで手に入れたトッキュウチェンジをもって
プラレールの直線レールをもって「とっきゅうちぇんじ!」と言ってるのが面白い。
大晦日とか元旦というのは、SE的には「仕事をしている日」という印象が残りやすいものである。
実際、私も、ここ2年ほどは落ち着いているが、
3~4年前までは「大晦日」や「元旦」は普通に仕事をしていた。
ストレイテナーと確率7では、
”「シャッフルで曲選択していって60分でリセット」を繰り返したら手持ちの曲全部聴き終わるまでにどんだけかかるんだ?”というのを検証した。
結果的にそのときは95回の「60分シャッフル」を繰り返すことで手持ち全曲を聴き終えたのだが、
確率の問題なので100回を超える時もあるし70回で終わるときもある。
ではその平均(最も頻度の高い回数)はどこなのか?というのは前回の終わりで疑問になっていた。
で、今回それを検証してみようと思い立ち、前回のプログラムを少し改造して実行してみた。
ふと思い出したので書いてみる。 昔のPG修正の失敗談である。
今年のクリスマスプレゼント