パスワード議論2(世代管理について)
前回はパスワード登録・変更等におけるエラーチェックに関していろいろ個人的な見解を述べたが、
少し違う方針の「エラーチェック」にパスワードの世代管理の考え方が存在する。
要するに”変更しようとしたパスワードは昔使ったことあるから変更できないよ”というやつである。
管理が何世代に及ぶかにもよるが、個人的にはこれも鬱陶しい仕様の一つになっている。
前回はパスワード登録・変更等におけるエラーチェックに関していろいろ個人的な見解を述べたが、
少し違う方針の「エラーチェック」にパスワードの世代管理の考え方が存在する。
要するに”変更しようとしたパスワードは昔使ったことあるから変更できないよ”というやつである。
管理が何世代に及ぶかにもよるが、個人的にはこれも鬱陶しい仕様の一つになっている。
仕事で担当しているのは基本的に業務システムがメインだが、
いくつかの例外を除いていずれも「ログイン画面」が存在していて
ユーザー名(ユーザーID)とパスワードを入力してシステムにログインしてから業務を行うタイプのものがほとんどだ。
担当してきた業務システムを見るに、この「パスワード」に関してはシステムによって様々な考え方が存在するらしい。
javaにはオブジェクトの内容をそのままファイルにして出力したり、そのファイルを読み込んでオブジェクトとして復帰させる方法が存在する。
Serializableというインターフェースを実装することでそれが可能になる。
ある目的のために少し勉強したことがあるので、簡単な実現方法と共にここにメモ書きを残す。
大晦日とか元旦というのは、SE的には「仕事をしている日」という印象が残りやすいものである。
実際、私も、ここ2年ほどは落ち着いているが、
3~4年前までは「大晦日」や「元旦」は普通に仕事をしていた。
ストレイテナーと確率7では、
”「シャッフルで曲選択していって60分でリセット」を繰り返したら手持ちの曲全部聴き終わるまでにどんだけかかるんだ?”というのを検証した。
結果的にそのときは95回の「60分シャッフル」を繰り返すことで手持ち全曲を聴き終えたのだが、
確率の問題なので100回を超える時もあるし70回で終わるときもある。
ではその平均(最も頻度の高い回数)はどこなのか?というのは前回の終わりで疑問になっていた。
で、今回それを検証してみようと思い立ち、前回のプログラムを少し改造して実行してみた。
ふと思い出したので書いてみる。 昔のPG修正の失敗談である。
UNIX系OSにはunix2dosと、その逆のdos2unixコマンドというのが存在する。
使い方(オプション)はほとんど同じだが効果(?)が違う。
主に改行コードを変換する目的で使用する。
先に述べたiconvコマンドと併用することで、UNIX系OS上でWindows系OS向けのテキストファイルを用意することが出来る。
テーブル・マテビュー・INDEXのDDLを取得して、テーブル(マテビュー)別にファイルに吐きだすスクリプト。
DBMS_METADATA.GET_DDL、DBMS_METADATA.GET_DEPENDENT_DDLをカーソルと併用して使用し、
オブジェクト毎にDDLを取得しつつ、ファイルへの出力はUTL_FILEパッケージで行う。
UNIXには標準でiconvコマンドというのがついている。
コマンド一つでテキストファイルのエンコードを変換してくれる手軽で便利な機能である。
iconvコマンドの使い方を含めて、本項で備忘録のため記載する。
UNIX系OSには、ファイルやディレクトリのタイムスタンプに限界値が設けられており、それを超えると変な日時に逆転してしまう。
⇒いわゆる「2038年問題」にあたる
UTC+9:00の日本において、その限界値は2038年1月19日12時14分頃である。
これを超える(これより未来の)日付を与えて変更しようとすると、
変更自体は可能だが変更結果が1901年12月14日等の変な日時になってしまう。
なお、touchコマンドは対応していない(2039年に変更しようとするとエラーになる)。