この会社辞めようと思ったソースコード＃Ｅ

>>920
1)if((Event & 0xFE)==0xFE)
2)if(Event & 0xFE)

1と2だと動作が違ってしまうが。

>>921
ごめん。
たしかに動作かわっちゃうね。

>>906に#define EMERGENCY_MASK 0xFE って行があったから、
条件を満たしている状態毎にif文きってるのかと勘違いしてたよ。

/******************************************
この会社・・・ってわけじゃないけど
倒産した会社のソースメンテナンス頼まれたが、
コメントがニュー速っぽいＡＡでいっぱいだった。
ﾐﾐ彡彡ﾞﾞﾞﾞﾞ""""""""ヾ彡彡彡
ミミ彡ﾞ　　　　　　　　　ﾐﾐ彡彡
ﾐミ彡ﾞ　＿　　　　＿ 　 ﾐﾐミ彡
ﾐミ彡 '´￣ヽ　　'´￣｀ ,|ミﾐ彡 　
ﾐﾐ彡　-=・‐'　〈‐=・=- .|ﾐミ彡　
　彡|　　 ／　|　　 　 　 |ﾐ彡　　　／　　
　彡|　　　´-し｀)　　／|ﾐ|ﾐ　　　｜
　 ゞ|　 　　　､,!　　　　 |ソ　　　<そりゃつぶれるだろ
　　　ヽ　'´￣￣￣`ﾉ /　　　　　｜
　　　 ,.|＼､　 　　' ／|､　　　　　
￣￣| ｀＼.`──'´／ |￣￣＼ 　
　　　 ＼　~＼,,／~　 /　　 　　 　＼

*****************************************/

条件を満たしているじゃなくて、条件の一部をだな・・・
徹夜明けで頭が朦朧としてて文章になってないな。
駄目駄目じゃん漏れ･･･とりあえず逝ってきます

>>911
お前の設計書は怖くて外注に出せない。一生ＰＧ汁。

ヘ_ヘ
ミ・・ ミ　ということにしたいのですね？
( ° )〜

この会社辞めようと思ったのはソースコードせいじゃなくて、
本当の理由は、自分が日本語不自由で周りとうまくコミュニケーション取れなくて
会社に居づらいからなんじゃないのかな？

>>927
自分のことデスカァ？

>>928
はい、そうです。

>>929
oh,me too!!

>914
>初めて

早く始めろ!

DDT汁!

>>932
…CP/M?

懐かしいったらありゃしない＜DDT

占領軍が消毒に使ってたやつだっけ？　＞＞DDT

プロレス技じゃなかったけ？>>DDT

>>936
Google先生によると、技ではなく、プロレス団体そのもののようですね。

>>937
技もあるよん。

デンジャラスドライバーテンリュウの略でDDT
http://www.wrestling-high.com/tenryu/h999/h054.htm

>>938
＞デンジャラスドライバーテンリュウの略でDDT
それは天竜が言ってるだけ。
もしくは、天竜の使うDDTのみを「ﾃﾞﾝｼﾞｬﾗｽﾄﾞﾗｲﾊﾞｰﾃﾝﾘｭｳ」という。

おいらはシンボル使いたかったのでZSIDでした

磁気テープのことか？

こちらはSIDです…
UFOの…進入を…キャッチしました。
速度は…ソル １．

>>942
ﾌｯ、ﾌﾙｰ

ぬるぽ

ｶﾞｯ

939は橋本ファン

コメントと、関数名と、実際に書かれている処理すべてが合っていないorz

>947
がんがれ。正しいのは唯一、実際に書かれている処理だけ……のはずだ。

/*
* 与えられた２つの Integer の差の絶対値を返す。
*/

public Integer multiple(Integer a, Integer b) {
　　return a.add(b);
}

>>949
ひひ、ご愁傷様です。

>>948
「コメントと処理が合っていないときは、多分両方とも間違っているだろう」
って言うのが通説でして.......

それどころかメソッド名まで

"２つの Integer"ってとこがあってるだけマシじゃないか。。。

で、ある日キレた椰子が>949のようなメソッドを粛正してくれようと
大ナタを振るうと
http://pc5.2ch.net/test/read.cgi/prog/1085306859/259
のような惨事を引き起こすこともあり。世の中、右も左もまっくら森じゃございやせんか。

ぬる

ぽガッ

ＤＢに生パスワードのカラムが！

ソースというよりＤＢ設計です。
世間一般に公開しているシステムなんですが
ＤＢに生パスワードのカラムがあります。
しかも実データのテーブルのバックアップが
/tmp やら / に aaa.csv などの名前であっちこっちに残っています。
下っ端の俺でも、誰でも、見れてしまいます。

えーっと会員数２０万人なんですが。。。
ヤバイなこれ。と思いつつも他の大小の問題がたーくさんあって改善できないままでいる。
こういうのってどこでも一緒なのかな？

>>957
ありえない
少なくともうちではだけど

バックアップが散乱してるのは好ましくないが
DBに生パスを入れるのは場合によるだろ

webメールを実装しようとしたらPOP3の生パスは
どこかに置いておかなきゃならんわけだし

いや、そこは生じゃなくて暗号化しておけよ
DBから取り出す時に複合化して送信されたパスワードとチェックすればいいだろ

DBに入れるレベルなんてポリシーによりけり。
ま、望ましくはないけどね。

DBは普通誰でも見られる状態にはないはずだから
それを誰でも見られるよーってところに問題があるんだと思うよ

バックアップcsvは問題外だけど

>>960
普通、復号化はしないだろ。

安全性から言えば暗号状態で保存しておいて、入力されたパスワー
ドを同じ関数で暗号化した結果と比べるくらいは普通だわな。当然
暗号化には逆演算ができないかきわめて困難なものを。

パスワードを何らかの方法で教えてくれるWebサービスってのは
どっかに生パスワードが保存されてるわけで、かなり不安になる。

>>964
でも、秘密の質問+答え形式のパスワード称号なら
その答えをキーにして暗号化してしまえばいいんじゃないか？
チェックサムみたいなものをつけてれば、一応、でたらめな答えは防げると

>>964
＞パスワードを何らかの方法で教えてくれるWebサービスってのは
＞どっかに生パスワードが保存されてるわけで、かなり不安になる。
なぜそういう結論になるのか教えてくれ。

>>965
普通はパスワード忘れたときのリマインダの話だと思うが（質問と答え）…

>>964
通信路での安全性を考えたら、その方法は使えない場合が多い。

たとえば、APOPのチャレンジレスポンスとか。
これは生パスワードに復元できていないと認証できない。

別にチャレンジ＆レスポンスでも、
生パスワードを復元できないとならない理由は無いと思うが…

クライアントサイドで２重に暗号化(ハッシュ化)してくれるなら、復元できなくてもかまわないが
APOPだとクライアントは不特定だからそうもいかないだろ

…そうなるか？
ただのハッシュならそういう仕様にしとけば問題ないと思うが？