5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :Ponkotsu Generator:04/02/21 20:16
この会社辞めようと思ったソースコード。
プログラマとして幻滅するソースコード。
プログラマを悩ませるソースコード。
Modula-2 ライクなソースコード。(゚д゚)ウマー
をつらつらと綴っていって頂戴。

ちなみにここは質問スレじゃないよ。
技術的な質問がしたいならム板に逝って。

2 :仕様書無しさん:04/02/21 20:19
● 過去スレ
1:http://mentai.2ch.net/prog/kako/997/997104873.html
2:http://pc.2ch.net/prog/kako/1001/10010/1001076034.html
3:http://pc.2ch.net/prog/kako/1015/10158/1015861447.html
4:http://pc.2ch.net/prog/kako/1021/10215/1021560641.html
5:http://pc.2ch.net/prog/kako/1029/10291/1029120005.html
6:http://pc.2ch.net/prog/kako/1029/10291/1029120005.html
7:http://pc.2ch.net/prog/kako/1036/10367/1036779521.html
8:http://pc.2ch.net/test/read.cgi/prog/1040451049/ (dat落ち中)
9:http://pc.2ch.net/test/read.cgi/prog/1045401372/ (dat落ち中)
A:http://pc.2ch.net/test/read.cgi/prog/1049973793/ (dat落ち中)
B:http://pc.2ch.net/test/read.cgi/prog/1054362467/ (dat落ち中)
C:http://pc.2ch.net/test/read.cgi/prog/1067794604/

3 :仕様書無しさん:04/02/21 20:21
● 関連
この会社辞めようと思った上司の一言#E
http://pc.2ch.net/test/read.cgi/prog/1075987262/

まな板娘、誕生の記録 (この会社辞めようと思ったソースコード#B)
http://pc.2ch.net/test/read.cgi/prog/1054362467/920-n

まな板娘[まないた・むすめ]

マ板における幾多の妄想の産物キャラのうちの一人。
上記過去スレ参照。
転機となる一言は該当スレ >>945 参照。
キャラ的には萌える要素満載だが、未だに絵はない。


というわけで今スレでも画像キボンヌ

4 :仕様書無しさん:04/02/21 20:31
>1

乙。

5 :仕様書無しさん:04/02/22 00:30
5?

6 :仕様書無しさん:04/02/22 06:56
6 goto 1

7 :仕様書無しさん:04/02/22 16:01
漏れ埋め立て乙。

8 :仕様書無しさん:04/02/22 16:10
>>7
氏め

9 :仕様書無しさん:04/02/22 20:11
乙〜

10 :仕様書無しさん:04/02/23 03:18
全スレ986のことだけど、デバックモードでしかしないんだったら
ゆるせるかなと一瞬思ったけど、デバックモードどそうでない状態で
プロトコル変わっちゃうの?そりゃまずいんでないですか。

11 :仕様書無しさん:04/02/25 08:10
>>10
typoばっかりある中で、そこに注視せよ、っつても無理のある事ではあるのだが、
いちおう、
#ifndef _DEBUG
なんだ…………。

12 :仕様書無しさん:04/02/25 12:52
なかじま かおる 1960ねん あいちけん とよかわしうまれ。26さい。
おまんこなめてーよぅ えっちする女の子がほしい
チツちゃん クリちゃん すき!すき!

13 :仕様書無しさん:04/02/25 12:56
1960ねんうまれ。
   ↑
間違ってないか?
   ↓
26さい。


14 :仕様書無しさん:04/02/25 13:06
>>13
当時26歳だったのだよ。

15 :仕様書無しさん:04/02/25 13:07
>13
12は昔のファミコン用ゲームにあったコメント

16 :仕様書無しさん:04/02/25 13:08
20年も前にいったい何が?!

17 :仕様書無しさん:04/02/25 13:11
URLぐらい貼っといてよ。
http://www.geocities.co.jp/SiliconValley/8474/yoiko/yoiko5.html

18 :仕様書無しさん:04/02/25 23:46
>>12
それってでもソースじゃないよな。バイナリに直接・・・ってもはやどうでもいいが。

19 :仕様書無しさん:04/02/27 01:36
「GridBagLayout使うと可読性落ちるからやめましょう」
と言われたんだが、レイアウト合わせるためにラベルやテキストフィールド幅に
定数値多用しているのよりはよっぽど可読性高いと思った今日この頃。


20 :ヽ(´ー`)ノ:04/02/27 10:10
>>10
(そいつにとっては)可読性低い。


21 :仕様書無しさん:04/02/28 00:55
可読性をうるさく言う奴に限って自分では読まない

22 :仕様書無しさん:04/02/28 01:46
>>21
自分で読むからこそ、うるさく言うけど

23 :仕様書無しさん:04/02/29 21:03
コーディング規約をうるさく言う奴に限って自分では読まない


24 :仕様書無しさん:04/02/29 23:51
ツールの実行一発で判定/修正できるコーディング規約のみ指定する。
規約自体は必要だが、検査に人手を介するのはダメプラクティス

25 :仕様書無しさん:04/03/03 01:42
コーディング規約はいいんだが、
規約のためにいらん書類が増えるのは勘弁。

public class ClsYamashitaA0001 extends ClsUITantou001Gaichu0001

クラス1個作るのに「クラス概要仕様書」「クラス詳細仕様書」
「クラス仕様書一覧表」「クラス作成者一覧表」を書けと。

外注に丸投げしてヒマなのか?


26 :仕様書無しさん:04/03/03 02:02
>>25
あるにこした事はないが、まあ普通JavaDocだろうな。

27 :仕様書無しさん:04/03/03 15:00
>>25
結局ソース読むことになるから、いらないよな

同じようなクラスを重複して作らな無いような仕組みはほしい

28 :仕様書無しさん:04/03/03 16:05
社長自らが新人教育と称して
自分のキャパを超えた知識を教えている会社
知ったかぶりのTOPを持つと部下は最悪・・・
赤字プロジェクトはすべて責任を社員に押し付ける社長
小さな会社は社長が法律です


29 :仕様書無しさん:04/03/03 21:33
新人教育でコーディングシートにコーディングをさせる会社
よりはまだマシです。
まだあるのよ。こういう会社。

30 :仕様書無しさん:04/03/03 22:03
よく今どきコーディングシートなんか調達できるな。
まだ作ってるところあるのか?

31 :仕様書無しさん:04/03/03 22:14
>>30
コボラーが絶滅しない限りコクヨあたりが作ってくれるでせう。


32 :仕様書無しさん:04/03/03 23:19
>>26
ドキュメントはWordで作るという規約

33 :仕様書無しさん:04/03/03 23:30
クラスに「概要書」なんて求めるのは,
クラスを「サブルーチンの集合体」だと思ってるからに相違無い

34 :仕様書無しさん:04/03/03 23:31
エリカ・ユングって可愛くな〜い?

35 :仕様書無しさん:04/03/03 23:33
コーディングシートと鉛筆っていうのがまるっきり悪いとは言えないよ。

うちの会社の連中は新機能追加の修正とかの場合
いきなりソースファイル開いてあてずっぽでコピペし始めるからなぁ。
結果はもちろん突然脈絡も無く使ってもいないフラグを立てたりとかばっかり。

ソースコードじゃないけど別なチーム担当システムとの連携で発生した障害対応中
「とりあえずそっち側で日付がX日になってるデータを全部出してみて」と
そっちのチームの中堅クラスに言ったら
select * from XXXX
ってクエリを実行して結果をExcelにコピペしてフィルタとか使われた時には
本気でそいつらのシステム全て葬りたくなったなぁ。

36 :仕様書無しさん:04/03/03 23:45
コーディングシートって言うのは、その昔
端末の台数が限られている環境なんかで
プログラマがパンチャーさんにソースのパンチ(入力)
をお願いするために使われていたものだよ。

依頼からコンパイルが完了までどれだけの時間を要した
ことか(⊃д`)

37 :仕様書無しさん:04/03/04 00:04
>>35
そういう人たちはコーディングシートにもあてずっぽうで書き込むんだよ、きっと。

38 :仕様書無しさん:04/03/04 00:09
>36
タコなパンチャに当たるとパンチミスだらけでヒサンだたw
まあ、ふつうは別人がベリするので問題なかったんだが、
ベリを省略されることもあった。そういうときの話。
(ベリ=ベリファイ=別人が同じカードにまったく同じ内容を打ち、
食い違いがあったらハジく作業)

39 :仕様書無しさん:04/03/04 00:44
昔はコンパイルにもカネがかかったから、それの節約も兼ねてたとしても
今はそんな時代じゃないし。

40 :仕様書無しさん:04/03/04 00:47
>>36
ふるーいアセンブラとかFORTRANとか
カラムによって意味が決まってる言語の場合で
パンチカードとかで入力するの場合は、
あった方が便利だったそうだ。

41 :仕様書無しさん:04/03/04 13:56
>「とりあえずそっち側で日付がX日になってるデータを全部出してみて」と

この要求に対して、

>select * from XXXX
>ってクエリを実行して結果をExcelにコピペしてフィルタとか使われた時には

このアプローチって有りに見えるが。
要求は満たしているんじゃないのか?


42 :仕様書無しさん:04/03/04 14:45
まあ間違ってはいないわな


43 :仕様書無しさん:04/03/04 15:35
いや、おかしい。感覚的に。理由を書いてみようか。

コピペ
 (再現性のない)オペレーションは極力するな。操作というものは間違えるものだ
execl
 db上で行うべきフィルタリングを何故に、よりによって表計算ソフトなぞつかう
 なんのためにsqlがあると思っているのか
データ量
 この場合は問題にならないだろうが、この方法はデータ量に上限がある

要求を満たせばいいという感じ方にも問題があるなあ。
ちゃんとsqlを切ることが出来る人ならどっちの方法を選ぶべきかは、自明だ。
まあ「この方法しか知らないとか思いつかない香具師のヘタレぶり」が話題なんだけど

44 :仕様書無しさん:04/03/04 16:06
要求さえ満たせばいい=動けばいい=それらしく見えればいい

なんつうか、糞コード量産する奴らの基本姿勢だな
まあ、それさえも出来ない奴もいっぱい居るけどなー

45 :仕様書無しさん:04/03/04 18:30
>>41
>このアプローチって有りに見えるが。
いや、中堅クラスでそーゆー「オラクルマスターうんこ色」レベルってのはちょっと…

46 :仕様書無しさん:04/03/04 18:57
>>43
べつに>>35で槍玉に上がってる奴らを擁護する気は無いが、
障害対策のためのデータ抽出なら別にいいと思うが。
むしろ>>43みたいにガチガチにかたまって、柔軟性のなさの
方が障害対策時には厄介だとおもうけどな。

47 :仕様書無しさん:04/03/04 20:51
>>43
まあ、excel とするべき所を、execl としているところが、
プログラマらしくていいな、と思ったり。

48 :43:04/03/04 21:41
>>46
了解。それもまた一つの見解だ。
#ガチガチっていうが、俺は「ちゃんとselectすべきだ」って言っただけだけど。二次障害に直面したことが無いんだろうね

>>47
_| ̄|○

49 :仕様書無しさん:04/03/04 21:57
>>48
見苦しいね…

50 :仕様書無しさん:04/03/04 23:30
>46
 どうまかり間違っても無駄だが。

 仮に日付を where に書いたとしてもインデックスが使われてない、という場合でも、
データ抽出にかかる時間は select * と変わらないよね。でも RDBMS がデータを送り出
す手間は明らかに減る。
 加えて、得られたデータを再加工する手間考えたら、ふつーに where 書いて当然だろ。

 だいたい、障害対応ってことはその RDBMS、本番稼働しているマシンじゃん。そんなの
に迂闊に select * かけたりしたら、それこそ二次災害起こしかねないんだがねえ。

 そもそもの条件が曖昧で、where で一発で取れない、ってんなら、ある程度余裕もたせ
て取ってきてから吟味するのはよくあることだが、日付限定できるのにしないってのは
馬鹿と言わずしてなんなのだろう。

51 :仕様書無しさん:04/03/04 23:52
本番稼動してるからといって全面的に信用してしまう姿勢が「ガチガチ」って言われるのだよ
問題が潜んでるから障害対策してるんだろ?

52 :仕様書無しさん:04/03/05 00:14
>>51
よくわからんが
RDBMS が信用できない状態で
テーブルの全件取ってこれるのか?

それだけでも
RDBMS が信用できないから
って理由は消えると思うのだが

53 :仕様書無しさん:04/03/05 00:33
多分、稼動2日目くらいで * で取ってきてもたいした数じゃなかったんだよ。


54 :仕様書無しさん:04/03/05 00:39
>>52
ガ チ ガ チ

55 :仕様書無しさん:04/03/05 00:58
俺 の ち ん こ だ け は ガ チ ガ チ

56 :仕様書無しさん:04/03/05 01:02
>>55
小さいけどな

57 :仕様書無しさん:04/03/05 01:03
>>56
何で知ってるんだ。ちなもに仮性でもあるのだが。

58 :仕様書無しさん:04/03/05 01:08
>>56
マイクロカーネルです。


59 :35:04/03/05 01:58
なんか論じられてる(w

>>この方法しか知らないとか思いつかない香具師のヘタレぶり
まぁ俺としても感じたのはそこ。
っつーかそんな奴が作ったシステムをどう信じろというのか…

ちなみに障害の原因ももちろん向こうのシステムだった。
詳細を述べるのは差し控えるが、要するにはデータ操作があったら必ず行う処理を
追加の時はやってて修正の時はやっていなかったという凡ミス。勘弁してくれ。

60 :仕様書無しさん:04/03/05 02:25
>>59
勘弁するから詳細よろ

61 :仕様書無しさん:04/03/05 06:48
コボラーにSQLを書かせるとWHERE句無しのSQLを書いてくるよ。
全件取得したデータを1件ずつIF文で処理対象か否かを判定するのさ。

..._| ̄|○ <何のためのSQLなんだ

62 :仕様書無しさん:04/03/05 09:19
>>61
っつーかそれが奴らのオンリーワンなやり方だし。
コボラーの手にかかればRDBだろうがXMLだろうが全てCOBOL色。
一体なんなんだよ固定長XML(うちの会社のコボラー命名)って。

63 :仕様書無しさん:04/03/05 09:38
delete する時は、
必ずselectして
行があるのを確認してからdeleteします。


64 :仕様書無しさん:04/03/05 09:46
彼等にはコダシルが必要なんだ。

65 :仕様書無しさん:04/03/05 10:17
deleteは必ずキー値で抽出して一件ずつ削除します。

66 :仕様書無しさん:04/03/05 11:01
今一緒に仕事をしてる先輩は最初、Accessのプロという触れ込みだった。
「教科書的な作り方をしてもパフォーマンスはでない。
テクニックをいろいろ知ってるから教えてやる」
みたいな感じの強気の発言してた。
でも、実際仕事をしてみると、そもそもセオリーをまったく知らないし
一般的なセオリーどおりに作ったよりぜんぜんパフォーマンスのでない
作り方しかできない人だった。

テーブルの設計でパフォーマンス出すために非正規化してるわけじゃ
なくて、そもそも「正規化」という言葉を知らなかったし。

SQLも自分では書けなくて、AccessのGUIツールで作って、それを
コピペしてるし。
あとあとマルチユーザーにも対応でるように、データベースは
SQL Serverかほかのものに変更できるように設計しようという
話が出たときに、なぜか動揺してて、SQL ServerもAccessから
接続できて今まで通りGUIでリレーション作れると教えたら
嬉しそうにしてやんの。

67 :仕様書無しさん:04/03/05 11:18
COBOLにて。
西暦2000年対応やっていたら、うるう年ベタ打ち発見。
YYが84の時か88の時か92の時か96の時…(略) ってなんだよぉ(涙

って、でもこのパターンはありがちなのかしら。

68 :仕様書無しさん:04/03/05 11:34
>Accessのプロ
この表現自体がかなり痛いわけだが。

69 :仕様書無しさん:04/03/05 11:34
このスレに出てくるような人間を生で見たい。 次プロジェクトが何千人月規模でCOBOL満載(MQで完全隔離)だから、嫌というほど見られるかな。

70 :69式フリーPG ◆hND3Lufios :04/03/05 12:33
DELETE文でWHERE句を設けずにループして一行一行消してるのはみたことあるな。
「日次処理のときパフォーマンスが出ないんです。この糞Windows!何とかしてください」
と言われてみたらそんなコードだった。

71 :69式フリーPG ◆hND3Lufios :04/03/05 12:34
失礼、WHERE句はあった。ただ、一行を指定するようなWHERE句だったな。

72 :仕様書無しさん:04/03/05 16:59
>>67
ヲレは取り敢えず、4年・100年・400年毎の補正は組み込んでるなぁ。
西暦3200年・・・・ヲレの作ったプログラムが1200年も使われるとは思えんw

73 :仕様書無しさん:04/03/05 17:14
>>72
2100年の事は考えないことにしている

74 :仕様書無しさん:04/03/05 19:18
>>73
まー、みんな芯でるだろうしな。

75 :仕様書無しさん:04/03/05 22:14
400年ルールのおかげでとりあえず2000年は救われた香具師>>73-74

76 :仕様書無しさん:04/03/05 22:27
閏年かどうかなんて、>>72の考え方なら一行で書けるだろうがよー
まったくよー

77 :仕様書無しさん:04/03/05 23:47
>>67
うちにもそういうのあった。
年ごとに各月の日数が定義してあるようなヤツ。

まぁ、何も見なかったことにした。

78 :73:04/03/06 00:27
漏れの場合は、Windowsのプログラム専門だからなあ。
2100年まで、Windows使ってるとも思えんしなあ。

と、20世紀のプログラマ達も、そう思っていたんだろうなあ

79 :仕様書無しさん:04/03/06 00:29
小惑星が衝突して自転周期が変わってしまう罠

80 :仕様書無しさん:04/03/06 02:37
最近、暦のほうを修正したほうがひょっとして楽なんじゃないかと思い始めたわけだが


81 :仕様書無しさん:04/03/06 08:36
>>80
禿同。
毎日11月23日なら尚良し。

82 :仕様書無しさん:04/03/06 08:56
>>80
11月23日生まれの人の年齢計算が大変だぞ

83 :仕様書無しさん:04/03/06 12:31
>>61-62
その方法はCOBOLとしては「正しい」コードだったらしいよ。
SQLで条件絞るよりもよっぽど速いそうなので。

プラットフォームが変わってもそれしか知らないのなら
ちゃんと教えてやらないといけない。

あー、当然Java屋がCOBOL書けって言われたときにSQLで
がりがりがんばってもきっと馬鹿にされるだけだぞ。


84 :仕様書無しさん:04/03/06 13:07
>>83
それってJavaとかCOBOLとかの問題じゃなくて、データベースの問題だと思うが。

85 :仕様書無しさん:04/03/06 13:10
>>83
ちょっと信じがたいのですが、そのCOBOL屋は信用できますか。
RDBMSの黎明期ならまだしも、今でもそんなにSQLが遅いとは考えにくい。

86 :仕様書無しさん:04/03/06 13:23
>あー、当然Java屋がCOBOL書けって言われたときにSQLで
>がりがりがんばってもきっと馬鹿にされるだけだぞ。

慣れてない環境でセオリックに組んでいてパフォーマンスでないのは
単に慣れの問題で、ベテランが教えてやればそれで済む問題だと思う。

DELETEで1レコードずつ消すのが早いとか裏技的なテクニックを
当然と思い込んでるのは明らかに勉強不足だから、周囲がその間違いを
教えてやっても、他の箇所でもいろいろ変な書き方をしてそう。



87 :仕様書無しさん:04/03/06 14:52
一行ずつ処理?
どうもCSVかなんかのテキストベースのテーブルを処理してるような感じがするな。

コボルはあまり知らないんだが、要するにDBエンジンに仕事をさせるための言語がSQLで、
DBエンジンにさせたほうが速い仕事もコボラーは自分でやりたがるんだろう。
必然的に総てのデータを処理したがるわけだ。
まあ、それが第三者が見て一番解りやすいやり方なのかも知れないけど。

確かにサブクエリが何層にもなったSQLや、5つも6つもつなげたユニオンクエリを書いて
一発で通る時の充実感は確かにあるけど、第三者のことは考えてないもんな。処理速度はこの方が速いんだろうけど。

だからコボラーにはデータベースは無理なんだって。

88 :仕様書無しさん:04/03/06 15:27
>>87
程度にもよるけど、サブクエリーがネストした程度のSQLなら普通に読んでもらいたい。


89 :仕様書無しさん:04/03/06 16:17
>サブクエリが何層にもなった
俺は一つのSQLにSELECTが13個ある命令を見たことがある。

90 :69式フリーPG ◆hND3Lufios :04/03/06 16:25
COBOLの時代はISAMだったんじゃないの?
よく知らないんだけど。

91 :仕様書無しさん:04/03/06 17:44
select * from (select * from (select * fromselect * from(select * from (select * fromselect * from(select * from (select * from(elect * from(select * from (select * from ta_data))))))))

92 :仕様書無しさん:04/03/06 17:46
( がおかしい。シモタ

93 :剛万太郎 ◆uuJAVAsys2 :04/03/06 17:48
カッコ悪い

94 :仕様書無しさん:04/03/06 18:22
>>91
from の後に select 書けるの?

95 :仕様書無しさん:04/03/06 18:24
>>87
プラットフォーム(広義の意)にあわせた開発をしてくれればいいんだがな。
つこて
>だからコボラーにはデータベースは無理なんだって。
こーゆー言い方しかできないやつは、全く別の環境にいくと使い物にならないやつになりそうだな。

96 :仕様書無しさん:04/03/06 20:32
客先のオサーン達は、CSVファイルという概念がいまだに理解できてません。
こんなオサーンを引っ張って開発せにゃならんと思うと鬱。

97 : ◆SparcUTLAw :04/03/06 20:42
>>96
俺も「CSVファイルの区切り文字は、タブ文字とする。」なんていう
客先SEのメールで目が点になった。
#いや、俺もタブ区切り嫌いじゃないが…それCSVじゃないよ…


98 :仕様書無しさん:04/03/06 22:40
from (select〜)は常識だぞ!
>>94が俺様の究極の13重サブクエネストのSQLを見たら100年かかっても理解できねぇだろうな。

99 :仕様書無しさん:04/03/06 22:52
>>98
そうなん?
select は where 節にしか書けないと思っていたのだが?

100 :仕様書無しさん:04/03/06 22:54
>>98
そんなネストが必要なのは
スキーマの設計の段階で終わっているからだと思うが?

101 :仕様書無しさん:04/03/06 23:15
流れを切って一つ愚痴を。
今回入ったプロジェクトの変数の命名規則が
「ソースファイル名+YYYYMMDD」
なんだが、非常に見にくい罠。
ちなみに言語はc。
発案者は誰なんだーっつーか死んでください

102 :仕様書無しさん:04/03/06 23:26
>>101
1つのソースファイルで、1日1つの変数しか宣言できないの?

103 :69式フリーPG ◆hND3Lufios :04/03/06 23:28
しかもローカル禁止とかw

104 :仕様書無しさん:04/03/06 23:30
>>99
俺も最近知ったけど、FROM句にも書けるんだよねぇ。

105 :仕様書無しさん:04/03/06 23:34
>>104
それどころかselect句にも書ける罠

106 :仕様書無しさん:04/03/06 23:59
失礼
DDMMの後に分と秒があった

107 :仕様書無しさん:04/03/07 00:03
>>106
時はないのか?

108 :仕様書無しさん:04/03/07 00:28
>>101

int hentai20040307000312=0;
int yamete20040307000313=0;
int sukebe20040307000314=0;
char ahan20040307000315[100];

?


109 :仕様書無しさん:04/03/07 00:36
select * from (select * from (select * fromSelect * from(select * from (select * fromSelect * from(select * from (select * from(Elect * from(select * from (select * from ta_data))))))))

大文字にした所をよくみるがよし。
通らないよコレ

110 :仕様書無しさん:04/03/07 00:43
IF〜
IF〜
IF〜
IF〜
・・・
条件多すぎ、おえねぇよ

モウヤメテェヨナ

111 :仕様書無しさん:04/03/07 01:21
SQLくらい勉強してくださいよ…
副問合わせぐらい覚えようよ、MySQLでも使ってない限り

112 :仕様書無しさん:04/03/07 01:41
>>111
ごめん。俺オラクルプラチナもっているけど既に忘れた。
なんかあったね。そういうの。

113 :仕様書無しさん:04/03/07 01:59
>>112
Oracle7のプラチナは9iのシルバーに劣るよな。
まじで。

114 :仕様書無しさん:04/03/07 02:01
ひとつのselect文はその結果自体が一つの表(つーかビュー)になってるわけだから
それをfrom句に書けるのは当然。という考え。

115 :仕様書無しさん:04/03/07 02:35
>>108
hoge.c

int hoge20040307023229=0;
int hoge20040307023243=0;
int hoge20040307023246=0;
char hoge20040307023250[100];

for(int hoge20040307023301=0;hoge20040307023301<100;hoge20040307023301++) {
 …

という感じになるのでは…

116 :仕様書無しさん:04/03/07 09:35
>>101
前の会社にも変な規則あったけど、そんなのは初めて。
世の中には変なことを考える人がいるもんだね。
意図がわからねぇ

117 :仕様書無しさん:04/03/07 10:19
>>105
どう書くのか教えて!

118 :仕様書無しさん:04/03/07 10:37
selectをselectに書く場合
select (select hoge from tbl),hoge2 from hogehoge


119 :仕様書無しさん:04/03/07 10:53
俺が見た究極のSQL
25連結ユニオンクエリ、、、鬼。


120 :仕様書無しさん:04/03/07 11:03
別名つけなされ

121 :仕様書無しさん:04/03/07 11:07
25回もUNIONしなきゃいけない理由ってなんだろう…?

122 :仕様書無しさん:04/03/07 11:17
や、俺が書いたんじゃねーから、読むのもウザかった。
どうもね、売上データに20種類ぐらいの場合分けがしてあって、
しかも、同じテーブルに一定の比率を掛け合わせたものを別々のデータとして扱う必要があったみたい。
それを計上日順にソートしなくちゃならないから、そうなった。

同じ内容の奴もいくつかあったみたいだけど。

123 :仕様書無しさん:04/03/07 11:21
>>118
ほほー、こんなのもアリなのか。
勉強になった。サンクス!

124 :仕様書無しさん:04/03/07 11:26
悲しいとき〜、
超苦労して書いた長いユニオンクエリやサブクエ多重ネストが通らなかったとき〜。
どのSelectが問題おこしてるか解らない〜!

125 :仕様書無しさん:04/03/07 12:17
>>123
いっとくが、select部分に副問い合わせを書くのはSQLに慣れた人から見ると
ここでよく紹介されるコボラー並みにみっともない行為だぞ。

FROM句に書いて結合させればいい話なんだから。

126 :仕様書無しさん:04/03/07 12:19
>>113
9iのプラチナ(当時)だけどね。今はゴールド扱いだっけ?

127 :仕様書無しさん:04/03/07 12:20
コボラーはみっともなくないぞ!

128 :仕様書無しさん:04/03/07 12:38
>>126
こんなヤシがいるから、オラクルマスタが改定されたんだな…

129 :仕様書無しさん:04/03/07 13:01
>>125
心配してくれてありがとん。
知識が増えて喜んでただけだよー。
どう使うか(使えないもの)は、ちゃんと考えるよ。


130 :125:04/03/07 13:50
うっす。
要らぬ心配だったようだな。失礼した。

131 :仕様書無しさん:04/03/07 22:48
for (i=0; i<3; i++) {
  switch (i) {
    case 1:
      …
      break;

    case 2:
      …
      break;

    case 3:
      …
      break;

    default:
      break;
  }
}


  ふ  ざ  け  る  な

132 :仕様書無しさん:04/03/07 22:58
forとswitch使いたかっただけと違うんか

133 :仕様書無しさん:04/03/07 23:24
>>131
おれ、一連のシーケンスを実行するときは、そういうループ書くけどな。
大抵、switchの前と後ろに、なんかやりたいことがあるんだけど。
ふざけてるんじゃないよ。

134 :仕様書無しさん:04/03/07 23:27
プログレスバー進めたいとか
処理をいくつかのステップに明確にわけたい事情があったのかも。
あるいは、その名残のようなものなのかも。

まあ、違うんだろうけど

135 :仕様書無しさん:04/03/07 23:31
各ステップの処理を関数にでもして、
各関数を順に呼ぶだけの方が解り易いのに…。

136 :仕様書無しさん:04/03/08 00:07
時と状況によっては、>>131のコードは問題ないと思うんだが。
要は、中にどんな処理を書くかでしょ

137 :仕様書無しさん:04/03/08 00:14
>>131が怒ってるのは、default: についてだと思うよ

138 :仕様書無しさん:04/03/08 00:15
まあ最初の1ループはまるっと無駄だよね

139 :仕様書無しさん:04/03/08 00:20
中でiの値書き換えてるんだよ
...それはそれでブチ切れる鴨

140 :仕様書無しさん:04/03/08 00:24
>138
「case 3:」も無駄だよね

141 :仕様書無しさん:04/03/08 00:26
>>137
>>140
お前等>>131を馬鹿にしすぎです。w

142 :仕様書無しさん:04/03/08 01:50
iの値を書き換えていくわけか
i++があるから1少なく書くわけだな
なんかオラワクワクしてきた

143 :仕様書無しさん:04/03/08 12:39
俺よりベテランで、今までVBやってきたという人とC#の仕事をしてる。
「Cになれて無いから」と頻繁に言い訳するけど、仕事が遅いのはそれ以前の
問題というか。
(C#とCは違うと、それとなくツッコミを入れてもCと言い続けてるし)

F1でヘルプが出る事を知らなかったし、デバッグのやり方も、ソースを変更
して実行を繰り返すやりかたで、ブレークポイントを仕掛けてステップ実行
とか全然やらないの。
横からチラチラと覗いていても原因が分かるレベルのバグだったので、
それとなく「ここにブレイクポイントを入れて、ステップ実行したら。。。」
という感じでアドバイスしたけど、その後もステップイン、ステップオーバー、
とかを使い分けたりしないで、ひたすらステップインをクリックするだけ。
余計なメソッドやループに入ってしまったら、ステップインのアイコンを
連打して脱出で効率悪すぎ。

このあたりの統合環境の使い方はVBでも同じはずなんだけど、この人はVBで
いままで何をやってきたのか謎。

ヘルプの使い方とかデバッグのやり方とか、それとなく本人の前でやって
みせるのだけど、ぜんぜん盗んでくれないし。

144 :仕様書無しさん:04/03/08 22:30
>>142
>なんかオラワクワクしてきた
ワラタ

145 :仕様書無しさん:04/03/08 23:00
>>143
俺より10年ベテランの人はJP1スクリプトのことをJAVAスクリプトと呼ぶ
・・・JP1スクリプトって何者?


146 :仕様書無しさん:04/03/08 23:18
>143
当方リアルVB厨(2年目)ですが、
それはソイツが糞なだけですよ。
デバッグくらい自分レベルでも当然やってますし。
因みに副問い合わせのSQL書けない方、自分以下ですのでそこんとこよろしこ

147 :仕様書無しさん:04/03/08 23:32
>>146
副問い合わせ?
SQLでのすべての問い合わせは「こうやって取り出したい」と思ったの
かければいいんだよ。楽しみながら実験していけば、
本読んで勉強するより短時間に覚えられるよ

148 :仕様書無しさん:04/03/08 23:32
>>143
あんたいい人だ。・゚・(ノд`)・゚・。
がんがれ。

149 :仕様書無しさん:04/03/08 23:43
>>143
多分VSの一枚目しか持ってなかったんだよ。

150 :仕様書無しさん:04/03/09 00:17
>146
 んじゃあ、「副問い合わせを使わずに、副問い合わせ使って欲しいデータを、SQL 一発で取る」
のはレベル上なのか下なのか?(w

 MySQL は副問い合わせ使えないから、join で書き直す癖が付いたなあ……癖抜くのに少し
手間取った(w

151 :仕様書無しさん:04/03/09 00:21
>>150
書かないのと書けないのは違うだろ。

152 :仕様書無しさん:04/03/09 01:14
遅レスだが。。。
>>131
俺も似たようなコード見たことある。
もっとヒドイ

for(i=0; i<2; i++){
if( i==0)
f000();
if( i==1 )
f001()
if( i==2 )
f002()

f(); // なにやら共通っぽい処理

if( i==0)
f010();
if( i==1 )
f011()
if( i==2 )
f0012()


}

みたいな。
頭の硬い年よりはイラネ

ま、辞めたけど

153 :仕様書無しさん:04/03/09 09:33
131も152もどちらにもありえない判定文があるのは
こういう書き方をするプログラマにとっては必然なのだろうか。

154 :仕様書無しさん:04/03/09 09:47
>>153
直接関係あるかどうか知らんが、
そういう香具師の多くがデバッグ用printfに副作用のある式を入れたりする。
で、「普通に動くんですけど、デバッグオプション付けると動かないんですぅ」
とか言い出す。

155 :仕様書無しさん:04/03/09 10:58
>>154
「デバッグオプション付けると普通に動くんですけど、取ると動かないんですぅ」
っていうパタンもあるし

156 :仕様書無しさん:04/03/09 12:41
>>155
デバッグビルドのまま納入しますけど、何か?

157 :仕様書無しさん:04/03/10 00:30
>>153
ヒント:iはグローバル変数

158 :仕様書無しさん:04/03/10 00:34
グ・グム〜

159 :仕様書無しさん:04/03/10 01:40
sedで

s/ "/"/
s/  "/"/
s/   "/"/
s/    "/"/
s/     "/"/
(中略)
s/                          "/"/

CSV末尾の余分なスペースを取りたかったらしい。
性器、もとい

160 :159:04/03/10 01:42
正規表現使えよ、とオモタ。

#途中で送信してしまった。。

161 :仕様書無しさん:04/03/10 17:54
>>76
#defineMAXDAY(y,m)(((m)==4||(m)==6||(m)==9||(m)==11)?30:((m)==2?(((!((y)%4)&&((y)%100))||(!((y)%4)&&!((y)%400)))?29:28):31))
どうだ?

162 :仕様書無しさん:04/03/10 18:51
>>161
正しいか否かを確認する気にもなれないぞ
「一行で書ける」は「一行で書くべきだ」とは違う
たとえ十行を超えたとしても、もっと読みやすい書き方で書いてある方を評価する


163 :仕様書無しさん:04/03/10 19:50
>>162
まあ、「1行で書ける」と言われたから1行で書いたのだろう。
これを読みやすいからという理由で、複数行で書いたのでは、
>>76への答えにはならんだろう。

しかしな、>>161よ、お前は>>76をもう一度読み直せ。
これがテストなら、お前の答案は0点

164 :仕様書無しさん:04/03/10 19:55
>>161
#defineMAXDAY(y,m)(((m)==4||(m)==6||(m)==9||(m)==11)?30:((m)==2?( ((y)%4)||(((y)%100)==0)&&((y)%400)?28:29):31)
どうだ?


165 :仕様書無しさん:04/03/10 20:31
>>76は「閏年かどうか」と言っているので
これでいい
((year % 4) == 0) && ((year % 100) != 0 || (year % 400) == 0)

166 :仕様書無しさん:04/03/10 20:39
>>164
#define MAXDAYS(y,m) (((m)==4||(m)==6||(m)==9||(m)==11)?30:((m)==2?(((y)%4)||!((y)%100)&&((y)%400)?28:29):31))
ちょっと修正させてもらった

167 :仕様書無しさん:04/03/10 21:05
日数算出で、
現在日付から年と月1つずつずらしながら
延々ループ回して求める関数。
10年やってんならユリウス日ぐらい知ってろ!

168 :仕様書無しさん:04/03/10 21:13
・・・ライブラリ使わないのか?

169 :仕様書無しさん:04/03/10 21:16
きっとライブラリ作る人なんだよ

170 :仕様書無しさん:04/03/10 21:33
(mktime(&to_tm) - mktime(&from_tm)) / 86400;
じゃダメか?


171 :仕様書無しさん:04/03/11 01:42
ユリウスとグレゴリオの違いがわからない

172 :仕様書無しさん:04/03/11 01:49
文字数が違う

173 :仕様書無しさん:04/03/11 01:53
グレゴリアはショタ。ユリウスは年増キラー。

174 :仕様書無しさん:04/03/11 14:22
>>170
from_tm をどうやって求めるかも書かないと片手落ちだぞ

175 :仕様書無しさん:04/03/11 15:23
最近は片手落ちも差別語らしいね
まあ2ちゃんねらーには関係ないか

176 :仕様書無しさん:04/03/11 15:53
片輪より片手落ちのほうがかなり直接的な表現だけど、
なぜかカタワのほうが差別度は高いな。
どうでもいいけど。

177 :仕様書無しさん:04/03/11 16:15
そのうち「手抜き」も差別用語になるかな。

178 :仕様書無しさん:04/03/11 20:48
めくらタイピング

179 :仕様書無しさん:04/03/11 21:09
>>167
ユリウス暦は常識 (とは言え使われていない) が、
ユリウス日を知っている人はそう居ないのでは?

180 :仕様書無しさん:04/03/11 22:06
そのうち「口抜き」も差別(ry

181 :仕様書無しさん:04/03/11 22:17
そのうちけんけんも差別遊戯と(ry

……そろそろ流れ戻そうよ。

182 :仕様書無しさん:04/03/11 22:45
>>178
いいなそれ。あえて広めようぜ。俺は面倒だからやんないけど。

183 :仕様書無しさん:04/03/12 04:46
おさわりタイピング

184 :仕様書無しさん:04/03/13 00:09
接触打鍵

185 :仕様書無しさん:04/03/13 08:34
我流一本指打法

186 :仕様書無しさん:04/03/13 11:35
コロンブスメソッドって知ってる?

187 :仕様書無しさん:04/03/13 16:43
十字キーで全て解決!

188 :仕様書無しさん:04/03/13 16:58
interruput_fuck( )
{

}

189 :仕様書無しさん:04/03/14 01:08
>>188
ワラタ

190 :仕様書無しさん:04/03/14 17:30
>>164 >>166
最短
inline MaxDays(int y,int m){return m==4||m==6||m==9||m==11?30:m==2?y%4||!(y%100)&&y%400?28:29:31;}


191 :仕様書無しさん:04/03/14 21:39
>>179
天文オタなら常識

192 :仕様書無しさん:04/03/14 22:42
inline MaxDays(int y,int m) { int max_days[] = {略}; return max_days[y*12+m-1]; }

193 :仕様書無しさん:04/03/15 01:06
>>192
y は西暦で与えるんでしょうか?
 そんな膨大な配列をインライン展開されたら目が眩みそうでし。


194 :仕様書無しさん:04/03/15 01:27
static constな配列にしとけば全然大丈夫。きっと。
つか、引数が定数なら計算結果の値だけになるかも。こっちの可能性は低いけどな。わら。

195 :仕様書無しさん:04/03/15 02:23
>>194
まさか>>193
int max_days[] = {略};
にstatic constを付けるとか言うつもりじゃあるまいな?

196 :仕様書無しさん:04/03/15 03:13
>>190
inline MaxDays(int y,int m){return m-4&&m-6&&m-9&&m-11?m-2?31:y%4||!(y%100)&&y%400?28:29:30;}

197 :仕様書無しさん:04/03/15 03:48
おまいらのコードじゃあ全部会社辞めたくなるな。
エラーチェックくらいしる!


198 :194:04/03/15 04:48
>>195
ダメなの?
# ダメだと主張するコンパイラがあることは知ってるけど。

199 :194:04/03/15 04:50
>>197
細かいinline関数にはエラーチェックを入れるなよ?
あいだをとって、assert()にしとけ。

200 :仕様書無しさん:04/03/15 07:12
>>191
それは普通常識とは言わん。

201 :仕様書無しさん:04/03/15 10:00
>200
すべての人間にとっての常識なんてあるか?
範囲は必要だろう。

202 :仕様書無しさん:04/03/15 12:11
200にとって、「日本人なら常識」な事は常識とは言わないらしいね

203 :190:04/03/15 13:00
>>196
マイリマシタ > orz

204 :仕様書無しさん:04/03/15 14:55
>>196
int MaxDays(int y,int m){return m-2?31-(1&2644>>m):29-(y%4||y>1582&&!(y%100)&&y%400);} // 1<=y<=INT_MAX, 1<=m<=12
グレゴリオ対応。


205 :仕様書無しさん:04/03/15 19:13
そのうち >>196>>204 が各社のソースにコピペで氾濫する事でしょう。
その時は、是非以下のコメントを入れておいてください。

// この会社辞めようと思ったソースコード#D

206 :仕様書無しさん:04/03/15 22:34
さすがに>>204は却下されそう。
>>196>>190をもうちょっと分かり易いように
書きかえて使うかも。

207 :仕様書無しさん:04/03/15 23:16
m-2?31-(m+(m<8))%2:(以下略)
というのを考えたが、>>204と字数変わらんかった。

208 :仕様書無しさん:04/03/16 01:22
>>205
実際にコピペする機会がありそうだから怖いな

209 :204:04/03/16 13:29
>204 はコピペ禁止な。
代わりにだいたい等価な関数を貼っておく。

#define SMALL_MONTH_BITS 1322 // 010100101010b
#define SMALL_MONTH_BITS_1 (SMALL_MONTH_BITS << 1)
#define GREGORIAN_YEAR 1582
//#define GREGORIAN_YEAR 1699
// return value={28-31}, 1<=year<=INT_MAX, 1<=month<=12
int MaxDays(int year, int month)
{
int days;

assert(1 <= year && 1 <= month && month <= 12);
if (month != 2) {
if (SMALL_MONTH_BITS_1 >> month != 0) {
days = 30;
} else {
days = 31;
}
} else {
if ((year % 4 != 0) ||
(year > GREGORIAN_YEAR) && (year % 100 == 0) && (year % 400 != 0)) {
days = 28;
} else {
days = 29;
}
}
return days;
} // MaxDays() End

あと、グレゴリオ対応は意味が変なので、紀元後〜1582あたりに対応と訂正で。


210 :仕様書無しさん:04/03/16 16:50
>>209
グレゴリオ対応とか要らん。
それと、等価な関数……を自分で書けないような奴が、このスレに
来るとも思えん。


211 :204:04/03/16 22:13
上司が >>210 の会社は今月で辞めようと思った。
#define MaxDays(y,m) 31


212 :仕様書無しさん:04/03/16 22:17
>>211
日本語もうちょっと勉強しろ

213 :仕様書無しさん:04/03/16 22:26
>>212
すみませんでした。許してください。

214 :仕様書無しさん:04/03/16 22:36
やだ

215 :仕様書無しさん:04/03/16 23:43
>>214
そんなこといわないで、ゆるして〜

216 :仕様書無しさん:04/03/17 00:54
会社を辞めようと思った。上司が>>210。今月。

217 :仕様書無しさん:04/03/17 09:05
if(上司 == 210){
switch(month){
case 今月: 会社を辞めようとおもった。 break;
default:   温もりに包まれる。 break;
}
}

218 :仕様書無しさん:04/03/19 03:24
うるう年に対応は当然だが、うるう秒に対応してるのは見たことが無い

219 :仕様書無しさん:04/03/19 11:05
必然性がない。


220 :仕様書無しさん:04/03/19 11:20
>>219
んー、そうでもないよ。

221 :仕様書無しさん:04/03/19 11:28
そもそもうるう秒は予測可能なのか?
それとも過去のうるう秒の話?

222 :仕様書無しさん:04/03/19 11:31
ここが噂のdate timeについて語るスレですか?

223 :ヽ(´ー`)ノ ◆.ogCuANUcE :04/03/19 11:33
http://jjy.crl.go.jp/Pub/leapsec.html
規則性は無さそうだな。

仮に規則性があったとしても、一秒単位で時刻の調整をするくらいなら
NTP で同期取った方がいいんだろう。

224 :仕様書無しさん:04/03/19 11:34
>>223
ファームとかではちゃんとやるぜ

225 :仕様書無しさん:04/03/19 11:47
>>218
NTP

226 :仕様書無しさん:04/03/19 12:26
閏秒があると、秒が 58 → 59 → 60 → 00 → 01 と一回だけ 60 になる。
OSによって対応度合いが違うだろうけど、アプリ側で対応してないと
拙い事もあるだろう。

まあ、12/31 から 1/1 の間にリアルタイムでデータ収集してるとか
そーゆーシステムでもない限り関係ないわけだが。

227 :仕様書無しさん:04/03/19 12:27
>>226
秒数のカウントとか、影響は色々あるでしょ。

228 :仕様書無しさん:04/03/19 12:38
>226

そんなもん、解析時に考慮すればいいだけだろ。

229 :仕様書無しさん:04/03/19 12:41
char* mage()
{
  char ret[MAX_RET];
処理

  return ret;
}


230 :仕様書無しさん:04/03/19 12:44
おめーら皆素人だろ。
閏秒ごときを考慮しなきゃなんないシステムなんかない。
年間どころか週間一秒の誤差を考慮する必要あるシステム上げてみぃ!


231 :仕様書無しさん:04/03/19 13:03
>>230
リアルタイムに絡むシステムなら、結構関係するのがあると思うが。
イベント間の時間間隔がクリティカルになる計測系とか。

232 :仕様書無しさん:04/03/19 13:15
>>231
そうだとしてもどのように対応するの?
閏秒ってある程度溜まった時点でやるよーっていってやるじゃない。
それを管理してる側かそこからリアルタイムに時刻をもらってない限りは、通常の時刻調整と同じだろ。

233 :仕様書無しさん:04/03/19 13:34
>>232
>イベント間の時間間隔がクリティカルになる計測系とか。

イベント間の時間間隔は相対的なものだ。
うるう秒は絶対的なもの。

ここでは絶対的な時間が(時計やカレンダーみたいに)
クリティカルな意味を持たなければいけない。


234 :仕様書無しさん:04/03/19 13:45
>>233
各イベントがタイムスタンプ持ってたら?

235 :仕様書無しさん:04/03/19 13:59
>>234
その出力時刻がシステム内で定義された時刻か、外界の時刻かによるでしょ?

時間間隔でクリティカルなシステムなら、外界の時間を当てにしない。
外界の時間が大事なら、それに従う。

外界の絶対時間が重要なシステムって、基準時を管理してる組織だけじゃないのか?w


236 :仕様書無しさん:04/03/19 14:03
>>235
> 外界の時間が大事なら、それに従う。

で、外界の時間が閏秒を入れていたらどうする?

237 :仕様書無しさん:04/03/19 14:08
秒単位の絶対時刻で記録するような計測システムはまずいことになりそうだが。

238 :仕様書無しさん:04/03/19 14:12
>>236
外界の時間を何で取得するかによるでしょ?
普通にシステムコールしてるならば、それがフォローしてるし、OSがカバーしてる。

それ以外でどっかと通信して時刻を取ってる場合、予めその仕様に明記されているはず。
秒は0から60ですよって。

239 :仕様書無しさん:04/03/19 14:13

↓のスレで馬鹿がオナニーしてます
http://sports5.2ch.net/test/read.cgi/base/1076476572/l50


てめえの趣味はてめえでホームページでも作ってやれ。
ここは公共の掲示板だ。オナニーする場所じゃねえ。


↑このコピペを書きむだけでいいです。協力おねがいします。

240 :仕様書無しさん:04/03/19 14:17
>>238
> 秒は0から60ですよって。

で、いつ60があるのかわからなければ秒数が計算できないでしょ?

241 :仕様書無しさん:04/03/19 14:19
>238 本気でそれで問題ないと思っている同僚がいたら会社辞めたくなりそうだ

242 :仕様書無しさん:04/03/19 14:22
>>240
仕様でそのように書かれていれば、外部から時間を取り込む際に変換するだけ。

>>241
逆に通常業務で閏秒とか考えてる奴がいたら嫌だけどね。

大体さ、閏秒を考慮しなくちゃいけない場面って今までに存在したか?
普通にOS上で動くアプリであれば、そもそもそんな時刻存在しないし。

243 :仕様書無しさん:04/03/19 14:43
>>242
> 仕様でそのように書かれていれば、外部から時間を取り込む際に変換するだけ。

じゃ、その変換プログラム、擬似コードでもいいから書いてみてよ。
1つ目のイベントがYYYY年MM月DD日23時59秒で、
2つ目のイベントがYYYY年MM月dd日0時0秒だったとして、
1つ目のイベントから2つ目のイベントまでの秒数がいくつか、
閏秒がいつ入るかわからなくてもちゃんと計算できるやつ。
もちろん閏秒が入っている時には2秒と答えるように。


244 :仕様書無しさん:04/03/19 14:45
>242 マジ、こいつが同僚だったら転職考えるな。
自分の狭い世界だけで「ありえない」とか判断する奴、最低。

245 :仕様書無しさん:04/03/19 14:55
何必死になってんの?

246 :仕様書無しさん:04/03/19 15:01
>>243
つうかさ、相対時間が必要ならば、外部から時間は取らないよな。
仕様レベルであなたの前提がおかしい。
もし、過去に遡ってそういうのが必要ならば、閏秒があった年月日を予め与えて
そのイベント間にその時刻があったかを考慮すればいいだけ。
与えるのは人がやるしかない、それは当たり前。

>>244
ありえないとはいってないだろ、存在したかと聞いただけ。
絶対的な時刻差が必要ならば、外部から時刻を取らずに自分で時刻基準を持つだろ普通。


247 :仕様書無しさん:04/03/19 15:09
>>234
イベント間の時間の距離が問題となる状況で
その記録方法にタイムスタンプを採用しているのは
根本的な設計ミスだと思う。

ま、確かにそんな糞設計をしていれば 2038年問題なんて
心配する必要は無かったろうな。それぐらいしか利点は無いが。


248 :仕様書無しさん:04/03/19 15:09
>246
> つうかさ、相対時間が必要ならば、外部から時間は取らないよな。
> 仕様レベルであなたの前提がおかしい。

アッパレな先入観だな。
発行元がタイムスタンプを作成するシステムなんていくらでもある。
タイムスタンプ間の秒数が必要になるシステムだっていくらでもある。
たまたまあんたがそういうのに関わらなかっただけ。

よかったね、その「たまたま」が起きて。

249 :仕様書無しさん:04/03/19 15:10
>>247
> イベント間の時間の距離が問題となる状況で
> その記録方法にタイムスタンプを採用しているのは
> 根本的な設計ミスだと思う。

世の中、システム全体を設計できる案件ばかりではあるまいに・・・

250 :仕様書無しさん:04/03/19 15:13
>>248
逆にさ、発行元が閏秒のままそんなデータを垂れ流すほうが糞仕様だと思うけど。
屁理屈だよ。あんたの意見。


251 :仕様書無しさん:04/03/19 15:14
>>249
日本標準時を管理してる組織以外で、閏秒のままを外に出す必要のある設計ってあるのか?


252 :ぷろじぇくとりぃだぁ:04/03/19 15:18
おえらこんなとこでウダウダやってないでとっとと仕事シルヽ(`Д´)ノゴルァ

253 :仕様書無しさん:04/03/19 15:19
時間に秒単位の精度が重要なシステムで閏秒が問題になるのは、設計が悪い。時間と時刻は違う。
秒単位の時刻が重要なシステムなら、閏秒以前にどうやって時刻を構成するのか教えてくれ。
本音は、スレ違いだからいい加減にして欲しい。

254 :仕様書無しさん:04/03/19 15:21
>>250
> 逆にさ、発行元が閏秒のままそんなデータを垂れ流すほうが糞仕様だと思うけど。

そういう糞システムは全部あんたが無償で再設計してくれるみたいな言い方だな(藁

強弁するのはいいが、自分の視野の狭さを恥じる心も持ったほうがいい。
世の中、JSTと同期している機器だって一杯あるし、
そこからの絶対時間を信用する必要があるシステムだってある。

ま、どうでもいいスレ違いになっちまったから、俺はこの話題から降りるけど。

255 :仕様書無しさん:04/03/19 15:21
>>253
ハードとして、電子だっけか?の振動を数える機械を内蔵して・・・。w


256 :仕様書無しさん:04/03/19 15:29
>>253
スレ違いなのは禿道。だから
> 時間に秒単位の精度が重要なシステムで閏秒が問題になるのは、設計が悪い。時間と時刻は違う。
> 秒単位の時刻が重要なシステムなら、閏秒以前にどうやって時刻を構成するのか教えてくれ。
こういうマヌケな燃料は遠慮してくれないか?


257 :仕様書無しさん:04/03/19 15:31
>>253
>本音は、スレ違いだからいい加減にして欲しい。

いや、"糞仕様" という点でこのスレの意図にしっかり沿った
内容だと思う。


258 :仕様書無しさん:04/03/19 15:34
だから、そこまで時間の差が重要なシステムならば、設計段階で考慮するって。
そうではない日常使うアプリに出力する時間差にまでそんなことを気にする奴がいたら、そいつが馬鹿なだけ。

259 :仕様書無しさん:04/03/19 15:34
>>254
>世の中、JSTと同期している機器だって一杯あるし、
>そこからの絶対時間を信用する必要があるシステムだってある。

一点、突っ込みを入れさせてもらう。
それは「秒単位」で、か?

260 :254じゃないが:04/03/19 15:40
>>259
> それは「秒単位」で、か?

漏れはmsec単位のタイムスタンプ付きの情報が0.01-10/secぐらいで送られてくる
システムに関わったことがあるよ。実際に使うのはsecまでだったけど、なんか規則
でmsecまで記録するんだと。

261 :仕様書無しさん:04/03/19 15:44
>>260
だから、それはその相手装置内のタイムスタンプでしょ?
そんなの幾らでもあるよ。

そうじゃなくてJTSから取る時刻を秒単位で行ってるかじゃないのか?
通信による遅延があるから意味ないじゃないっていいたいんでしょ?>>259は。

262 :仕様書無しさん:04/03/19 15:50
>254
貴方がそういうシステムを知ってる物知りさんだってのはわかったけど・・・

それで、それらのシステムは閏秒に対応してたの?

263 :仕様書無しさん:04/03/19 16:12
わざわざ恥を晒しにきた260がいるスレはここですか?

264 :254じゃないが:04/03/19 16:47
>>261
> そうじゃなくてJTSから取る時刻を秒単位で行ってるかじゃないのか?

JTSってJSTのことか?
だとしたらたしかmsec単位で同期取ってたと思うが、ちょっと曖昧。
少なくとも秒単位では取れてた。

> 通信による遅延があるから意味ないじゃないっていいたいんでしょ?>>259は。

遅延があるから相手装置のタイムスタンプを信用せざるを得ないわけだけどね。
って、まさかJSTからの遅延を言いたいんじゃないだろうな?



265 :仕様書無しさん:04/03/19 16:52
JST、というか日本標準時と厳密に同期をとっているシステムだったら、閏秒は重要だな。
時刻→時間差の変換には気を使う必要がある。
そんなの滅多にないと思うし、想像もつかないけど、きっと世の中にはあるんだろう。

それ以外の場合は不要。

266 :仕様書無しさん:04/03/19 16:54
> そうじゃなくてJTSから取る時刻を秒単位で行ってるかじゃないのか?
> 通信による遅延があるから意味ないじゃないっていいたいんでしょ?>>259は。

いいかげん自分の見苦しさに気付け


267 :仕様書無しさん:04/03/19 16:56
>>265
秒単位が「厳密に同期」かよ…マジで自分の常識の狭さに気付いてないのかね…

268 :仕様書無しさん:04/03/19 16:57
>>254
こういうやつがいたら、会社辞めたく(辞めさせたく)なるな。

269 :265:04/03/19 16:58
>>267

日本語読めてる?

270 :仕様書無しさん:04/03/19 16:59
>267 気付いてないみたいよ、>268たんは(苦笑

271 :仕様書無しさん:04/03/19 17:01
>268 そう思うのなら、君は他の業種に転職したほうがいいと思うよ

272 :仕様書無しさん:04/03/19 17:03
>>266 - >>277
揚げ足ばかりじゃなくて、きちんとした反論しろよ。
自分は高見から見てるつもりかもしれないけど、全然話になってないよ。

273 :仕様書無しさん:04/03/19 17:04
>>266
たかが2chで時間潰してる新米SE君相手にムキになっても無駄だといいかげん気付け


274 :仕様書無しさん:04/03/19 17:08
>>272
これも揚げ足かな(藁

275 :仕様書無しさん:04/03/19 17:09
>>272
これも揚げ足なんだろうな(藁
次のレスも、そのまた次のレスも揚げ足なんだろうな

276 :仕様書無しさん:04/03/19 17:14
>>275
いいかげんにしとけ。電波取りが電波だぞ。

277 :仕様書無しさん:04/03/19 17:22
で、具体的な反論はできないと。
それに閏秒を実際にリアルタイムで処理してるとかの具体例も挙がらないと。

後から時間差を出すのに閏秒の考慮が必要ならば、その発生日時を渡すのはシステム的にありえる。
そんなのは当然だ。


278 :仕様書無しさん:04/03/19 17:34
>>277
> 後から時間差を出すのに閏秒の考慮が必要ならば、その発生日時を渡すのはシステム的にありえる。

それじゃ因果関係が狂いまくりだろ。そうじゃなくて正しくは
「発生日時から後から時間差を出すのなら閏秒の考慮をすることは
システム的にありえる。」だろ。
渡されるのが発生日時ではなくエポックタイムからの相対時間ならば
時間差を計算するのに閏秒など関係ない。


279 :仕様書無しさん:04/03/19 17:34
勉強になりそうなので閏秒を処理する必要のあるシステムの事例が知りたい。
俺の頭では考え付かないんだ。
このスレには期待してるんだけど。

280 :仕様書無しさん:04/03/19 17:37
>>277
> で、具体的な反論はできないと。
> それに閏秒を実際にリアルタイムで処理してるとかの具体例も挙がらないと。

いつのまに>>260は無かったことになったんだろうか...
自分に都合が悪い事を無視するってのは技術屋として最低だね。
まあ>>277が何を理解して何を理解してなくても俺には実害ないから
どうでもいいが。アフォらし。

281 :仕様書無しさん:04/03/19 17:39
>>279
http://www.google.com/search?q=%E9%96%8F%E7%A7%92&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8

よかったね、たくさんあって。

282 :仕様書無しさん:04/03/19 17:43
>281
"必要なシステム"の事例ではないような。

で、260は閏秒に対応してるシステムだったの?
つか、タイムスタンプを記録するだけの場合、閏秒ってどうやって保持するんかな。

283 :仕様書無しさん:04/03/19 17:58
>>282
> "必要なシステム"の事例ではないような。

必要だから対応してるんじゃねーの?
それとも、どれも酔狂か何かで対応してるとでも?

284 :仕様書無しさん:04/03/19 17:59
結論:
不毛な議論をしてるなぁ
いい加減飽きないか?

285 :仕様書無しさん:04/03/19 18:16
『糞システム』が『翼システム』に見えた。(鬱

286 :仕様書無しさん:04/03/19 18:28
>>280-281

アホかと。

閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
システムとして対応する必要があるかどうか、重要かどうかとは別。

287 :仕様書無しさん:04/03/19 18:41
>>286
なんだコイツ。。。
ただ受け付けるかどうかと閏秒処理するのと同じだとでも思ってるのかよ
マジで馬鹿だな。。。

288 :仕様書無しさん:04/03/19 18:42
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。


289 :仕様書無しさん:04/03/19 19:28
話がそれてきました。

290 :仕様書無しさん:04/03/19 19:37
    スレ違いの話題
--------------------------↑ ここまで

--------------------------↓ ここから
「この会社辞めようと思ったソースコード#D」

291 :仕様書無しさん:04/03/19 20:01
#define SORT_DIRECTION_A 0
#define SORT_DIRECTION_D 1
↑のように書いていたら、いつの間にやら、

//#define SORT_DIRECTION_A 0 // アップをローマ字で書くな
#define SORT_DIRECTION_U 0

と修正されていた……。

292 :仕様書無しさん:04/03/19 20:24
>>291
で、再修正しておいたのか?


293 :仕様書無しさん:04/03/19 20:26
スペルを省略しないように再修正をかけておけ。

294 :仕様書無しさん:04/03/19 20:37
//#define SORT_DIRECTION_A 0 // アップをローマ字で書くな
//#define SORT_DIRECTION_U 0 // アップじゃねえよ禿
#define SORT_DIRECTION_AFTER 0

295 :仕様書無しさん:04/03/19 20:51
//#define SORT_DIRECTION_A 0 // アップをローマ字で書くな
//#define SORT_DIRECTION_U 0 // アップじゃねえよ禿
//#define SORT_DIRECTION_AFTER 0 //なげーよ、ばか。
#define SDA 0


296 :仕様書無しさん:04/03/19 20:54
//#define SORT_DIRECTION_A 0 // アップをローマ字で書くな
//#define SORT_DIRECTION_U 0 // アップじゃねえよ禿
//#define SORT_DIRECTION_AFTER 0 //なげーよ、ばか。
//#define SDA 0 // 何故か AFTER がスルーされている・・・
#define SORT_DIRECTION_A 0


297 :仕様書無しさん:04/03/19 21:07
//#define SORT_DIRECTION_A 0 // アップをローマ字で書くな
//#define SORT_DIRECTION_U 0 // アップじゃねえよ禿
//#define SORT_DIRECTION_AFTER 0 //なげーよ、ばか。
//#define SDA 0 // 何故か AFTER がスルーされている・・・
//#define SORT_DIRECTION_A 0 // だから省略するなよ
#define SORT_DIRECTION_AGE 0

298 :仕様書無しさん:04/03/19 21:14
Dは何の略?

299 :仕様書無しさん:04/03/19 21:37
デスマ

300 :仕様書無しさん:04/03/19 21:39
INITIAL-D(デスマ)

301 :仕様書無しさん:04/03/19 21:40
ダメポ

302 :仕様書無しさん:04/03/19 21:49
突然蒸し返す事の
ドケチな秒単位課金プロバイダとか閏病考慮要るかもとか

303 :仕様書無しさん:04/03/19 22:03
Sort順って、ふつうAscending/Descendingを使うような…

304 :303:04/03/19 22:18
ああ、だから>>291はホントは正しいって話ね。ハイハイ。

305 :仕様書無しさん:04/03/19 22:56
こんだけの説明でわかるのか。
すげーなおい。


306 :仕様書無しさん:04/03/19 23:00
>>291
でもさ、SORT_DERECTIONまで略してないなら、最後まで略すなよと言いたくなる。


307 :仕様書無しさん:04/03/19 23:02
みんな!
そんなことをいちいち気にしていたらコードなんて1行も書けないぜ!

308 :仕様書無しさん:04/03/19 23:05
>>307
変数名・定数名は一番悩む部分だぞ。


309 :仕様書無しさん:04/03/19 23:30
>>308
俺は悩まない。
自分のルールを持ってるから。
もちろん、規約があれば準拠するが。

310 :仕様書無しさん:04/03/19 23:45
むしろ略すならDIRECTIONの部分の方を略した方がいいかと思う。
DIRECTIONがなくてもASCENDINGとかDESCENDINGとか付いていれば十分だし。

311 :仕様書無しさん:04/03/19 23:48
ASCENDING_SORT/DESCENDING_SORTでいいと思われ

312 :仕様書無しさん:04/03/19 23:58
つーか、命名規則とかある場合がほとんどだと思うんだけど
そんなことないんすか?
仕事するときは、大体ルールがあるけどなー

まぁ、それでも、英語で悩むわけでorz

313 :仕様書無しさん:04/03/20 00:09
>>312
うちみたいな零細企業にはコーディング規約も命名規則もありません
前いた会社にはあったけど

314 :仕様書無しさん:04/03/20 00:28
ASC/DESCでいい

315 :69式フリーPG ◆hND3Lufios :04/03/20 00:30
>>314
SQLっぽくてそれがいいね。

316 :仕様書無しさん:04/03/20 00:49
>>191
天文オタはそう居ない。

317 :仕様書無しさん:04/03/20 00:51
>>316
超亀レスイイね

318 :仕様書無しさん:04/03/20 01:46
よーし、パパも亀レスしちゃうぞー

>>33
クラスだから、詳細設計より概要設計の方が重要なのであ?

319 :仕様書無しさん:04/03/20 02:52
給湯室で電気ポットでお湯沸かそうと思ったらよ、
コンセントに挿すほうんところにとんかつソースがべっちょりついてたんだよ。


320 :仕様書無しさん:04/03/20 03:26
>>308
ハンガリアン【我流】命名するようになってからはけっこう楽になった。
あんたもどう?

321 :仕様書無しさん:04/03/20 04:22
結局プログラマという人種はスレ違いだろうが討論がお好きなようで・・・

322 :仕様書無しさん:04/03/20 04:27
>>308
時々それに悩みすぎてコーディングがえらく遅い子いるよね・・・

323 :仕様書無しさん:04/03/20 05:27
>>319
そのまんまですね。

324 :仕様書無しさん:04/03/20 05:35
>319
できれば「べっちょり」という言い方をやめて欲しいものだ。
我が故郷の言葉では「べっちょ」=「お○んこ」なのだよ。

そんなの(゚听)シラネといわれそうだが。

325 :仕様書無しさん:04/03/20 05:54
給湯室で電気ポットでお湯沸かそうと思ったらよ、
コンセントに挿すほうんところにとんかつソースがおまんこりついてたんだよ。

326 :仕様書無しさん:04/03/20 06:29
>>320
じゃあ漏れも今後はニッポリアン【我流】命名しようかな

327 :仕様書無しさん:04/03/20 07:13
>>311
SORTが前にきたほうが、入力補助とかで並ぶからいいような。

328 :仕様書無しさん:04/03/20 07:19
ハンガリアンとかニッポリアンとか言われても、でんでん分かんねーYOヽ(`Д´)ノ
具体的に、どうやるのか教えてくらさい。

329 :仕様書無しさん:04/03/20 07:53
じゃあ、おれは英語リアンで

330 :(゜Jし゜):04/03/20 09:19
この前見たテーブルの列名
table1.RirekiNum
table2.RirekiSeq
table3.RirekiNo
table4.RirekiBango
頼むから名称くらい統一してくれ…

331 :仕様書無しさん:04/03/20 09:23
>>330
多分全部違うんだよ。
数値、連番、No、番号・・・それでもNoと番号は一緒だな。w


332 :仕様書無しさん:04/03/20 09:35
>>331
Noは0から始まってて、番号は1から始まってたりするともう。

333 :仕様書無しさん:04/03/20 09:47
RirekiYes があったりするとか。

334 :仕様書無しさん:04/03/20 10:03
BangoがBingoのタイプミスとか。

335 :仕様書無しさん:04/03/20 10:12
#define MAX_MIN_VALUE 300

・・・どっちなのかはっきりしろ。


336 :仕様書無しさん:04/03/20 10:20
最大値の中にも種類がいくつかあって
その中の最小値なんじゃね?

337 :仕様書無しさん:04/03/20 10:23
>>336
いや、最小値として設定することが許される最大の値だろう。

338 :仕様書無しさん:04/03/20 10:50
MAXのファンなんだよ。

339 :仕様書無しさん:04/03/20 10:52
>>338
新幹線か?


340 :仕様書無しさん:04/03/20 10:55
>>339
アムロのおまけのほう。

341 :仕様書無しさん:04/03/20 11:00
連邦の白い奴か

342 :仕様書無しさん:04/03/20 11:01
MAXってまだ解散してないの?

343 :仕様書無しさん:04/03/20 11:09
>>341
いや、マクロスの青い髪の奴。

344 :仕様書無しさん:04/03/20 11:17
マックス桐島

345 :仕様書無しさん:04/03/20 13:54
俺は会社でマックスって呼ばれてるよ

346 :仕様書無しさん:04/03/20 14:17
( ´∀`)<オイデ マックス! エサノ ジカンヨ♥

347 :仕様書無しさん:04/03/20 17:05
概要設計なんてのは設計ごっこだよ。
詳細設計と呼ばれているフェーズを徹底的に行うべし。

デマルコ『デッドライン』より

348 :仕様書無しさん:04/03/20 17:07
>>347
そんなものはどうでもいいんだよ!
動けばいいんだよ!動けば!

349 :仕様書無しさん:04/03/20 18:12
「動いている状態」を定義しないと、動けばいい、というのも満たせないぞ。

350 :仕様書無しさん:04/03/20 19:07
俺が動いていると思ったら、それが動いている状態だよ。
文句ばっかり言ってないでさっさと作れよ

351 :仕様書無しさん:04/03/20 19:51
目立系の仕事って設計ごっこのフェイズ長いよな。
プロパーが実装知らないからだけど。
スレ違いでした。


352 :仕様書無しさん:04/03/20 20:18
>>347
「詳細設計と呼ばれているフェーズ」ってそんな重要か?
何か俺の考えてるのと違うものを言っているだと思うが…

353 :仕様書無しさん:04/03/20 20:32
>>352
俺もデッドラインを読んでそこに引っかかった。

デマルコ曰く
 デバッグの時間が開発の大部分を占めるのなら、デバッグ自体を無くせばよい。
 バグのほとんどはインタフェース部分に潜んでいる。
 すべてのインタフェースをプログラムコードと一対一で対応できるほど丁寧に設計しろ。
 そうすればバグを激減でき、デバッグしなくてもよくなる。

インタフェースの設計は基本設計フェーズでやるものだと思うので、引っかかった。
しかし、どのフェーズで実施するかはどうでもよくて、
インタフェースを丁寧に設計することが主張の本質なので、
trivial だとみなせばいいよ。

354 :仕様書無しさん:04/03/20 20:36
>>353
インターフェースについてはその通りだが、
「trivial」という言葉の使い方がわからん。
普通、「trivial」は「些細な」とか「取るに足りない」とかいう意味なんだが、
何が些細で取るに足りないんだ?インターフェースじゃないよな?
デマルコの主張も些細だとは思わんし。謎だ。


355 :仕様書無しさん:04/03/20 20:37
「どのフェーズで」という部分を trivial だと書いたつもり。
誤解を招く語順だね、すまん

356 :仕様書無しさん:04/03/20 20:48
>>353
> インタフェースの設計は基本設計フェーズでやるものだと思うので、引っかかった。

デマルコの言っているインターフェースはもっと具体的な、型なんかの情報も
含んだもの。だから詳細設計で正しい。


357 :仕様書無しさん:04/03/20 20:59
基本設計時のインターフェースと
詳細設計時のインターフェースは
別ものですか?

358 :仕様書無しさん:04/03/20 21:02
デマンコって誰?

359 :仕様書無しさん:04/03/20 21:06
>>356
そうかな。
たとえばコンポーネントの開発を外部(他チーム、外注チームなど)が行うと仮定する。
設計書とともに、class や interface の仕様を共有するはず。

具体的に言えば、コンポーネントのコンテキストを説明する仕様書のみならず、
class や interface のソースファイル(ないし .jar ファイル)も渡す。


デマルコが言うのは、
すべてのコンポーネントを設計で抽出し、レビューを重ね、
そのインタフェースの設計を厳密に行えというものだと理解している。
開発を外部が行うか自分のチームが行うかは関係しない。

コンポーネントを同定するのは基本設計。
コンポーネント間の関係を示すインタフェースを設計するのは基本設計。
インタフェースに従って設計するのは詳細設計。
上記の定義をもっているので、基本設計フェーズと認識している。

デマルコの問題提起は、基本設計までに抽出されるものでは粒度が粗すぎるということ。
正しさを誰も検証できないということ。
それをとらえて「設計ごっこ」と呼んでいるのです。

#件の書では「管理ごっこ」の方がインパクトある言葉ですが。



360 :仕様書無しさん:04/03/21 01:40
>305
某ネットオークションのCGIに渡すパラメータには表示順制御パラメータとして
o1=d (逆はo1=a)
てのがある。てゆーかリンクのURLにaとあったから試しにdにしてみたら通った。
漏れ的にはトリビア(ORDER BY ASC/DESC)が役に立ってしまった瞬間だった。
オークション止めたくはならなかったがw

361 :356:04/03/21 04:25
>>359

> デマルコの問題提起は、基本設計までに抽出されるものでは粒度が粗すぎるということ。

だからもっと具体的に定義したインターフェースを練れってことだろ。
だから詳細設計で徹底的にやれってことだろ。

362 :仕様書無しさん:04/03/21 07:28
詳細設計時に問題が発生し、基本設計にまで影響があることが判明した場合にどうするか、
を決めておけばいいんじゃなかろうか

基本設計はここまでやるべし、詳細設計はこうすべし、
なんてガチガチに決めてしまうのはオーターフローと変わらんと思う

363 :仕様書無しさん:04/03/21 07:50
でも書く紙が決まってるからな。
基本設計書と詳細設計書のリリース期限があるからどっかで線は引かないと
なんないのね。

>コンポーネント間の関係を示すインタフェースを設計するのは基本設計。

になってない所多いよ。
データ構造すら基本では決めないとかね。

364 :仕様書無しさん:04/03/21 07:59
方法論を教科書として鵜呑みにしている初心者のスレはここですか?

365 :仕様書無しさん:04/03/21 08:08
>>364
確かに方法論は多種多様で、「小中学生の教科書の鵜呑み」の様なスタンスは誤りだけど

366 :仕様書無しさん:04/03/21 13:44
方法として定義するための方法が欲しいねえ

367 :仕様書無しさん:04/03/21 16:06
詳細設計の段階で、ソースと一対一で対応できるほど丁寧に設計することは、
・プログラムのほとんどの部分ではやらないが、
・インターフェイスについては行え
ということではないのか?

詳細設計前にインターフェイスをどこまで設計しておくか、については、
詳細設計段階でインターフェイス以外の部分に戻りが発生しない程度に詳しく
でいいんじゃないの。


368 :仕様書無しさん:04/03/21 16:08
壮観な滝ですなあ

369 :仕様書無しさん:04/03/21 16:42
プログラマは猪突猛進な人が多いのかな?

370 :仕様書無しさん:04/03/21 17:11
引数に float をとるとして、
Float.NaN をちゃんと検査してるか?という話。

371 :仕様書無しさん:04/03/21 22:42
>>370
不勉強で申し訳無いけど
「NaNの検査」ってどうやるの?

372 :仕様書無しさん:04/03/22 01:05
「ナンノの検査」やりたい…


373 :仕様書無しさん:04/03/22 01:12
「ナンノの検査」

ttp://my.reset.jp/~mars/btg/document7/sukeban2a.htm
>抜き打ち検査と言ってもハタから見るとほとんどレイプまがい。
>国家公務員にしては、やってることが非道すぎます。

374 :仕様書無しさん:04/03/22 01:38
おっさんage

79 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)