アカウント名:
パスワード:
# つーか、わたしが公務員だった頃は「疑問点は相談してね」って指示出してたもんだが。
という実装になってるのではないかと。
『10人同時に押しても大丈夫! イ○バ物置』なんてフレーズが頭によぎってしまったわけですが, あーゆー形で同時に乗れるものならまだしも ボタンを一斉に同時に押すってどうやってテストしたんだろ?とか思ってしまいます.
『せーの!』でやって『おい, A君! 0.1秒早いよ! B君は 0.2秒もたってる!』とか怒鳴り声が
名誉毀損で訴えられるのでAC
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
ありえねぇ・・・ (スコア:1)
面倒を避けて、PDFを印刷させて利用するというかなり
ひよった仕様になっているにもかかわらずこのバグ。
・・・・普通設計した段階で気付くだろ!
同時に使って何かが上書きされるって、別々のセッションの処理
であるにもかかわらず、同じワーキングエリアを使った・・と。
マルチスレッドで動くシステムの設計を一から勉強しなおしてください。
# 昔、BASICで同じ変数を別の場所で使っていた経験を思い出したなぁ・・・・
# 入れ子のfor 文が終わらなかったり・・・・
Re:ありえねぇ・・・ (スコア:2, 参考になる)
それに気付かない(気付けない)、職業不適合者がこの業界にゴロゴロしてませんか?
Re:ありえねぇ・・・ (スコア:0)
って、、、よっぽど修羅ってたのかなぁ。。。。
ありそうな話(もちろん想像) (スコア:1)
若手:「これだと他人の申告書がプリントアウトかもしれませんけど、いいんですかね」
上司:「いいんだよ、仕様書どおり作っておけば。それで問題が起こったって、設計か元請の責任なんだから」
---- * ---- * ----
趣旨・目的を無視して、「言われたことを言われたとおりにやればいい」と考える奴らが増えたと思う今日この頃。
Re:ありそうな話(もちろん想像) (スコア:0)
実装のみ受けた企業が趣旨・目的に従って指示に背けば、
確実にお金貰えなくなると思うんですが...。
趣味や公益のためにやってるなら兎も角、
仕事ではクライアントの注文がすべてだと思いますよ。
Re:ありそうな話(もちろん想像) (スコア:1)
>確実にお金貰えなくなると思うんですが...。
私が言いたかったのは、指示を矮小化して解釈し、その指示の趣旨・目的をないがしろにするってこと。
「指示や仕様をそう解釈できたから」といって、明らかに使い物にならないものを持ってくる奴にお金を払う人・会社はいないでしょう。
Re:ありそうな話(もちろん想像) (スコア:0)
Re:ありそうな話(もちろん想像) (スコア:0)
# つーか、わたしが公務員だった頃は「疑問点は相談してね」って指示出してたもんだが。
Re:ありそうな話(もちろん想像) (スコア:0)
(一応ある程度の指摘はしますが)相談なんてしませんねぇ。
指示通りに作成しますよ。
# お役所からの仕事を下受けた時の話なのでAC
Re:ありそうな話(もちろん想像) (スコア:0)
その通りです! だって趣旨・目的に沿って指摘や提案をしても結局バカ見るのは下請けの方だもん。
アホな元請に限ってただ黙って言う事を聞くだけのイエスマン下請けを使いたがるしね。
Re:ありえねぇ・・・ (スコア:2, すばらしい洞察)
設計してなかったに1ガバス
Re:ありえねぇ・・・ (スコア:1)
すんません、脳内補完で勝手にPDFにしてました。
嘘です。
Re:ありえねぇ・・・ (スコア:1)
大丈夫なように設計したしテストも終わってるということですが、
今回は何故か”2人同時に印刷ボタンを押すと”他人のデータが
でてくるようになってた ということで流出したそうです。
この理由付けが後からの言い訳的付け足しで無ければどんな理由
なんでしょうねぇ・・・教えて!偉い人。
Re:ありえねぇ・・・ (スコア:2, すばらしい洞察)
ちゃんと10人分出た。
で、2人同時にボタンを押して違うプリンターからだすと
他人のが出てきた。
#多分こんなところじゃないかと想像してみる。
適当に想像してみる。 (スコア:0)
→DBにデータを書き込み
→最新のデータをDBから取出してPDF出力
という実装になってるのではないかと。
Re:ありえねぇ・・・ (スコア:1)
「敵は海賊・A級の敵」を思い出してしまいました。まるで「バズーカ砲には耐えられても木の棒でぶん殴ったら壊れる装甲服」だ。
今回は「同時押しが10人なら大丈夫だけど2人だとまともに動かないコード」だったんですかね(と嫌味を言ってみる)。
想像ですが (スコア:1)
実運用は2wayとか4wayとか
#ホントの意味で同時に動きませんから > 1way
Re:ありえねぇ・・・ (スコア:1)
で、オーバーした1人が他の誰かとかぶった。
…まさかね
# ACなのでAC
Re:ありえねぇ・・・ (スコア:0)
Re:ありえねぇ・・・ (スコア:0)
Re:ありえねぇ・・・ (スコア:0)
『10人同時に押しても大丈夫! イ○バ物置』なんてフレーズが頭によぎってしまったわけですが, あーゆー形で同時に乗れるものならまだしも ボタンを一斉に同時に押すってどうやってテストしたんだろ?とか思ってしまいます.
『せーの!』でやって『おい, A君! 0.1秒早いよ! B君は 0.2秒もたってる!』とか怒鳴り声が
Re:ありえねぇ・・・ (スコア:1)
100人を均等に乗せないと無理と聞いたことがある気がしますが、本当のところどうなんです?
Re:ありえねぇ・・・ (スコア:0)
1回目は 60人くらいで潰れたそうです。
2回目でやっと成功とのこと。
名誉毀損で訴えられるのでAC
Re:ありえねぇ・・・ (スコア:0)
あのCMはその年の売り上げ上位の販売代理店の社長さんだかに集まってもらってやっている(TVに出られる)サービスを兼ねた一石二鳥のCMのはず。少なくとも当初はそう。あと100人乗れるのは雪国仕様のやつじゃないと駄目だそうです。
# 記憶ベースだけど読むクスリでそこの会社の人が話してた
Re:ありえねぇ・・・ (スコア:1)
そんな人が設計しているわけないです。
所詮客の言ってることをそのまま下に伝えててるだけですし。
(逆にそういうことがわかる人は疎んじられる)
Re:ありえねぇ・・・ (スコア:1)
自称OOPオタとして一言。
こういう問題を解決(?)するキーワードは「一対多」「多対多」です。
UMLのクラス図でいえば「*」を書く、あの場面です。
つまり、ナニとナニとが一対多(や多対多)関係なのか?を、きちっと押さえること、です。
それが出来なければ、少なくと鯖サイドのソフトは、絶対作るの無理っす。
個人的体験に基づく印象としては、
なんてーか「処理する」ことしか頭にないDQNは、しばしば居ますね。
そういう輩にナニが欠けてるかってーと、
「処理される対象」への配慮です。
だから、処理されるモノの個数の配分を、誤ったりしても(実際トラブるまで)気付かない。
#無理矢理喩えるなら、授業してる教師が、授業を受けてる生徒の数も確認してない、みたいな??
なお、対象ってのは、OOPでいえば「オブジェクト」です。
オブジェクトを、処理「される対象」だと見るところが、OOPの第一歩です。
そうすれば、まず、その個数が旨く配分されてるかどうか?とかが(ちょっと考えるだけで)判るでしょ、ってこと。
#クラス図や継承や隠蔽なんて二の次であり、基本でもなんでもないです。
#あんなもんをさも基本中の基本みたいに教えるのはDQN教科書です。
----
なお、デザインパターンは新しいものじゃないらしいですが(^^;、
DQNにとっては新しいものです。
つまり、知らない人は知らないんだから、
(たとえそれがデザパタのであろうと)教科書読んで、
もし知らないことが有れば、その時点で勉強すればいいんです。
というわけで、結城さんのマルチスレッド版デザパタの本、いいですよ。
俺もマルチについてはDQNくさいんで、精進しようとしてるところ。