アカウント名:
パスワード:
たとえば、IDを64ビットにして、上位16bitは発行日のUNIX時間の下位16bit、次の32bitはOpenSSLライブラリで作った疑似乱数、次の16bitはOSの疑似乱数発生機能で作った疑似乱数とかにすれば絶対被らない
何故、ぼくのかんがえたさいきょうのIDがバグ・非効率の原因になるということを理解できないのだろう……。
理解できないから「ぼくのかんがえたさいきょうのID」とか考えだしちゃうんですよ。
「ぼくのかんがえたさいきょうのID」の生成規則はエンドユーザーから納期間際、あるいは納入後に振ってくることが多い。
#「思ってたのとなんか違う」と言われた事がある。# 何回かリテイクした後「生成規則はこちら(エンドユーザー)で作るからおまえん所は実装だけすればいい」と言われた。# (13個ぐらいパラメータがあって、A+BがCより大きい事、CはDとF間の値である事・・・的な複雑な条件がいくつもあって# ユーザーがパラメータを一つでも変えたら整合性チェックを行い。# 生成規則違反の場合は最小の変更で生成規則を満足するIDを自動生成せよ。って仕様が文書で来た)# 最初は生成規則違反の場合はエラー表示後ユーザーが再入力する仕様だったが# 生成規則が複雑すぎて正解値が判らないから自動生成しろと仕様が変わった。# N社ってコーユー怪奇的な仕様が大好きだよね。
F通だからですよ。
F通のPJ部長が、WindowsとLinuxでSHA256算出結果が違うかもしれないとか言い出して、YESマンのテクニカルアドバイザ(藁)が肯定して独自実装となった。
確認と称して、数ギガ単位の文字列(失笑)を出して突き合わせてテスト完了とか本当にクソ。文字列の理由は、証跡を紙に出して顧客提出する必要があるからだそうで。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
IDは十分長くしておけばランダムIDでも被らない (スコア:1)
たとえば、IDを64ビットにして、
上位16bitは発行日のUNIX時間の下位16bit、
次の32bitはOpenSSLライブラリで作った疑似乱数、
次の16bitはOSの疑似乱数発生機能で作った疑似乱数
とかにすれば絶対被らない
Re:IDは十分長くしておけばランダムIDでも被らない (スコア:0)
何故、ぼくのかんがえたさいきょうのIDが
バグ・非効率の原因になるということを理解できないのだろう……。
逆じゃないかな (スコア:0)
理解できないから「ぼくのかんがえたさいきょうのID」とか考えだしちゃうんですよ。
Re: (スコア:0)
「ぼくのかんがえたさいきょうのID」の生成規則は
エンドユーザーから納期間際、あるいは納入後に振ってくることが多い。
#「思ってたのとなんか違う」と言われた事がある。
# 何回かリテイクした後「生成規則はこちら(エンドユーザー)で作るからおまえん所は実装だけすればいい」と言われた。
# (13個ぐらいパラメータがあって、A+BがCより大きい事、CはDとF間の値である事・・・的な複雑な条件がいくつもあって
# ユーザーがパラメータを一つでも変えたら整合性チェックを行い。
# 生成規則違反の場合は最小の変更で生成規則を満足するIDを自動生成せよ。って仕様が文書で来た)
# 最初は生成規則違反の場合はエラー表示後ユーザーが再入力する仕様だったが
# 生成規則が複雑すぎて正解値が判らないから自動生成しろと仕様が変わった。
# N社ってコーユー怪奇的な仕様が大好きだよね。
Re: (スコア:0)
F通だからですよ。
F通のPJ部長が、WindowsとLinuxでSHA256算出結果が違うかもしれないとか言い出して、
YESマンのテクニカルアドバイザ(藁)が肯定して独自実装となった。
確認と称して、数ギガ単位の文字列(失笑)を出して突き合わせてテスト完了とか本当にクソ。
文字列の理由は、証跡を紙に出して顧客提出する必要があるからだそうで。