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

プログラムセンスがある人とない人の違い 4 [無断転載禁止]©2ch.net

1 :仕様書無しさん:2016/06/26(日) 16:42:09.69
センスある人・・・例外をうまく使ってシンプルなコードを書くことができる
センスない人・・・例外を(俺が)使うとコードが複雑になるんじゃぁ、何が何でも処理しないと気がすまないんじゃぁ


プログラムセンスがある人とない人の違い 3 [転載禁止](c)2ch.net
http://tamae.2ch.net/test/read.cgi/prog/1423996665/

2 :仕様書無しさん:2016/06/26(日) 16:50:15.94
前スレではトムキャットしか使ったことのない能無しどものせいで時間を無駄にした。

3 :仕様書無しさん:2016/06/26(日) 16:52:05.62
いつからWebアプリケーションサーバーを使うプログラムの話になったのか?

4 :仕様書無しさん:2016/06/26(日) 16:53:35.65
あと例外じゃないコードの話をしてるくせに
例外だと言い張る組み込み屋(ネットワーク屋)もうざかったな。

5 :仕様書無しさん:2016/06/26(日) 16:54:08.63
>>3
いつからWebアプリケーションサーバーを使わないプログラムの話になったのか?

6 :仕様書無しさん:2016/06/26(日) 16:56:02.68
>>5
スレタイをよく見なさい。

7 :仕様書無しさん:2016/06/26(日) 16:57:15.75
組み込み屋の場合、例外(ではなくて本当は単なる状態処理)が
10個程度しかないんだろうね。

アプリ屋にとっては例外は標準だけで数十個
アプリやライブラリが使うものを含めるとそれ以上あるから
非対応の例外を共通の例外処理で処理して、
それ以外の対応が可能な場合だけ対応するというやり方になる。

そうするとほとんどの例外は共通処理で処理できるものになるって
いちいち処理を書いたりしないから、あとはまれにある標準以外の
対応を行う箇所だけコードだけが必要になって
故に例外を使うとコードはシンプルになる。

8 :仕様書無しさん:2016/06/26(日) 16:57:19.86
PHPやCGIのように、Apache配下で1リクエスト1プロセスが動くシステムを知らん奴のせいで、話が逸れたのだ。

あげく、nodeJSのように、1プロセス1スレッドで全てを捌くような
特殊なサーバーを持ち出して、例外処理をしなければ
サーバーが落ちるなどと極論を言い出した。

9 :仕様書無しさん:2016/06/26(日) 16:59:05.80
> PHPやCGIのように、
それっていまどきスレッドを使わない古いシステムじゃね?

10 :仕様書無しさん:2016/06/26(日) 16:59:34.96
例外は使う。
しかし、適切な処理を綺麗に書くために使うのだ。
アプリを落とさないためではない。

11 :仕様書無しさん:2016/06/26(日) 17:00:14.49
>>10
誰もアプリを落とさないために例外を書くなんて言ってないよw

12 :仕様書無しさん:2016/06/26(日) 17:02:56.65
>>9
じゃあスレッドを使うシステムが新しいのか?
ジジイを笑う中年のようだな。

PHPのシステムは世の中に溢れてるだから、現実を見ろ。

13 :仕様書無しさん:2016/06/26(日) 17:03:47.28
>>11
例外をログに吐けば十分=アプリを落とさない

おまいらの認識ってこの程度だよね。

14 :仕様書無しさん:2016/06/26(日) 17:04:27.24
>>13
だからお前の意見をかけって
逃げるなよ

15 :仕様書無しさん:2016/06/26(日) 17:05:06.43
>>6
スレタイをよーく見なさい。

16 :仕様書無しさん:2016/06/26(日) 17:06:13.18
>>13
何度も言うように、

「殆どの場合は」例外をログに吐けば十分
それ以外の処理が必要な場合だけ、特別にコードを書けばいいから
コードはシンプルになるって話をしている。

でお前がやるべきことは、特別にコードがたくさん必要になるから
例外を使うと大変だ。その特別にコードを見せてやる(ドンッ)
っていうことなんだから、そのコードがどんなのかをいうことだよ。

17 :仕様書無しさん:2016/06/26(日) 17:06:39.58
>>15
>>1の内容もよーくみなさい。

センスある人・・・例外をうまく使ってシンプルなコードを書くことができる
センスない人・・・例外を(俺が)使うとコードが複雑になるんじゃぁ、何が何でも処理しないと気がすまないんじゃぁ

18 :仕様書無しさん:2016/06/26(日) 17:06:57.91
>>14
何度も申し上げています通り
他社のAPI等、状態が安定しない呼び先に対して
安全に処理を書くための有効な手段となるのでございます。

19 :仕様書無しさん:2016/06/26(日) 17:07:35.78
>>18
具体的には?

20 :仕様書無しさん:2016/06/26(日) 17:08:05.73
>>17
>>1をよく読んだ上で、>>3を読みなさい。

21 :仕様書無しさん:2016/06/26(日) 17:08:15.04
>>19
前スレで書いたろ。しつこいよ。

22 :仕様書無しさん:2016/06/26(日) 17:09:31.37
>>21
申し上げているのでございます

23 :仕様書無しさん:2016/06/26(日) 17:10:12.14
>>22
ウルセーバカ

24 :仕様書無しさん:2016/06/26(日) 17:10:26.63
>>21
ございます

25 :仕様書無しさん:2016/06/26(日) 17:12:12.33
エラー処理とか書きたくないめんどい

26 :仕様書無しさん:2016/06/26(日) 17:12:50.23
いくらセンスがあろうとなかろうと仕様がクソだとどうしようもないね。

27 :仕様書無しさん:2016/06/26(日) 17:13:40.86
おまいら異常系の処理って言うと、ありえない状況を想像するから
例外処理でやることがなくなるんだろ?

結局そこの線引きの加減が下手なんだと思うわけよ。

28 :仕様書無しさん:2016/06/26(日) 17:16:08.32
シングルプロセスかマルチスレッドかはあまり問題じゃないと思うけどな。

じゃあ、マルチプロセスのプログラムはどうするのか聞きたいわ。

29 :仕様書無しさん:2016/06/26(日) 17:18:09.05
>>28
耐障害性の観点では、多少関係がある。

30 :仕様書無しさん:2016/06/26(日) 17:18:42.58
>>27
まあそうなんだろうな。

このスレにいる人間のうち、サーバー(ノード)が突然、落ちることまで想定している人間がどれだけいることやら。

31 :仕様書無しさん:2016/06/26(日) 17:26:14.60
>>16
そもそも、俺は「例外を使うと大変だ」とは言っていない。
簡潔に書くために例外を使うのだ、と言っている。

32 :仕様書無しさん:2016/06/26(日) 18:07:51.02
良く解らないんですが例えばファイルの読み込みメソッドでファイルが見つからないっていう例外が発生するとして
1.呼び出し側に戻り値で失敗を知らせるべき
2.読み込みに失敗してもその後のプロセスに影響の無い設計にすべき(あるなら例外で止めちゃう)
3.そもそも例外が発生しないように呼び出し側で引数をチェックすべき

他にもありそうですが混乱しまくりです
どういうのが推奨されるんでしょうか?

33 :仕様書無しさん:2016/06/26(日) 18:13:51.31
>>32
3は言ってることが分からない。

ファイルが存在しなくても処理を続ける仕様ならいいが、あまりそういうシステムはないと思うけどな。

ファイルがあるかもしれないし、ないかもしれないシステムなら、例外扱いでもいいし、ただの存在チェックエラーでもいい。

それを決めるのがプログラマ。

34 :仕様書無しさん:2016/06/26(日) 18:16:57.19
>>32
段階的に考えるといい。

通常は処理するためには何らかの「条件」が必要
その条件が全くない場合に汎用的で一番楽な方法は落ちること。
この場合にやるべきことは何もない。

次に楽な方法は(情報をログに吐くなどして)落ちること。
これも汎用的であり、また書くのは共通部分に一箇所ですむので手間は最小限。
通常はこっちを書いておく。

この2つは「条件」が何もなくてもできる。


> 1.呼び出し側に戻り値で失敗を知らせるべき
戻り値で知らせてはいけない。戻り値で知らせるとコードが複雑になる。
例えば呼び出し側の更に呼び出し側のさらに呼び出し側に伝える場合はどうするのか?
これを例外ならば何も書かずに自動的にやってくれる。

> 2.読み込みに失敗してもその後のプロセスに影響の無い設計にすべき(あるなら例外で止めちゃう)
これは「条件」が必要。いつでもそれをやっていいわけではなく、特定の条件を満たしている場合にのみ可能なこと。

あと「例外で止める」というのは言い方がおかしい。失敗したら例外を出力するべきだからだ。
あとは止めたければ発生した例外を処理するコードを何も書かない(最初に書いたようにログに出力して落ちる)
そして「条件」を満たした場合に限り、発生した例外を無視することも可能。

> 3.そもそも例外が発生しないように呼び出し側で引数をチェックすべき
それは不可能なので議論の対象にならない。

35 :仕様書無しさん:2016/06/26(日) 18:21:55.48
初心者は例外処理を書いて何もしていなかったり、そこで例外の情報を止めてしまうので、例外が発生していても正常終了にしてしまうからなあ。

36 :仕様書無しさん:2016/06/26(日) 18:33:34.21
技術は何でも初期は未熟なものだからどうしようもない話だけど、
初期の言語に「例外」というものがあれば、常識も変わっていたと思うけどね。

「エラーが発生すれば、プログラムはそこで停止するもの」というのが
初期の言語からの常識であれば、こんな議論はする必要がない。
え?エラーが発生したら止まる?それ当たり前ですよね?で終わる話。
停止させたくないときだけ、そのための処理を書く。
これを「例外」は実現している。

C言語が一番の障害だった。あれが「例外」を備えていないのに広く使われたせいで、
「エラーが発生しても、何もしなければプログラムはエラーが起きたのがわからないまま進む」
というのが初期の常識だった。そして、なにか書くのが面倒だから、
これはサンプルなのでエラー処理(エラーが発生したら停止する処理)を書いていません。
なんていうひどいサンプルが広まってしまった。本来はサンプルだからこそエラー処理を
きちんとして置かなければいけなかった。それを他の人は参考にするんだから。

だからエラー処理をまともにやるとコードが複雑になるって言ってる人は
たいていC言語しか知らない。(他の言語を使っても例外を正しく使っていない)

例外がある言語にとっては何も書かなくてもエラーが発生したら止まるというコードになってる。
これはC言語でいうエラー処理を書いた状態。そして止めずに回復できるという条件が揃ったときだけ
そのためのコードを書けば良いから楽なのだ。

37 :仕様書無しさん:2016/06/26(日) 18:38:51.52
>>32

> 1.呼び出し側に戻り値で失敗を知らせるべき
ファイルが見つからない例外を、戻り値に置き換えてみただけ。意味が無い。

そもそも、例外にしろ戻り値にしろ、失敗を呼び元に知らせるということは
呼び元に責任を放り投げているという事だが
それが正しい判断かどうか、という問題もある。

> 2.読み込みに失敗してもその後のプロセスに影響の無い設計にすべき(あるなら例外で止めちゃう)

例外で止めるのではなく、例外に対応するべきでは?
それが正しい設計ではなかろうか。

> 3.そもそも例外が発生しないように呼び出し側で引数をチェックすべき

結局どこかで問題に対応しないといけません。
それを適切な場所で対応するだけです。

38 :仕様書無しさん:2016/06/26(日) 18:42:33.74
> 呼び元に責任を放り投げているという事だが
> それが正しい判断かどうか、という問題もある。

極稀に勝手に修正してもうまくいく場合があるだけ
殆どの場合は呼び出し元の結果(エラーも含む)を返すのが正しい判断

39 :仕様書無しさん:2016/06/26(日) 18:42:55.78
殆どの場合は呼び出し元に結果(エラーも含む)を返すのが正しい判断

40 :仕様書無しさん:2016/06/26(日) 18:44:21.74
例えばファイルを開く関数があったとして
ファイルがなければ空ファイルがあることにして開いたら
空のファイルがあるのか、ファイルがないかの区別がつかない。

41 :仕様書無しさん:2016/06/26(日) 18:46:38.81
例えばファイルを開く関数があったとして
設定ファイルがなければデフォルトの値を返す関数があったとしたら、
それは「ファイルを開く」関数ではなく、「設定ファイルを開く」という
専用の関数になってしまう。

これは「極稀に勝手に修正してもうまくいく場合」の一例であり
汎用的な処理としては使えない。

42 :仕様書無しさん:2016/06/26(日) 18:51:02.12
このまま上に上に返していくと
最終的にユーザーに「ファイルがありません」とメッセージが表示される。
それが正しいのか、何か復帰処理を試みるのか。

>>41
ファイルを開く関数で、勝手にファイルを作ったら問題だ。
しかし、一つ上の呼び元では
そういったロジックが必要になるかもしれないだろ?

43 :仕様書無しさん:2016/06/26(日) 18:53:04.59
各メソッドがそれぞれの責任を果たすよう
適切な例外処理を書きましょうねって事だよ。

44 :仕様書無しさん:2016/06/26(日) 18:53:43.63
更に言うならば「設定ファイルを開く」という関数であったとしても
設定ファイルが複数種類あったらどうなるだろうか?

勝手に直すならば「ユーザー情報設定ファイルを開く」
「GUI設定情報ファイルを開く」などというファイルごとに関数を
作らなくてはいけなくなってしまう。

そうすることなく汎用的な関数にしたいならば「設定ファイルを開く」関数に
ファイルがなければデフォルトを渡すための引数を追加することで実現は可能だが
それだけ結局「呼び元に(デフォルト値をわたすという)責任を放り投げている」ことになり、
呼び出し元がやるのが正しいということになる。

45 :仕様書無しさん:2016/06/26(日) 18:55:00.85
>>42
> そういったロジックが必要になるかもしれないだろ?

「必要になるかもしれない」で作るのはYAGNI違反。
必要になったときだけやればいい。
つまりそれは「極稀に」うまくいく場合の一例でしか無い。

46 :仕様書無しさん:2016/06/26(日) 18:56:18.34
>>42
> 最終的にユーザーに「ファイルがありません」とメッセージが表示される。
> それが正しいのか、何か復帰処理を試みるのか。

デフォルトの動作を安全側に倒すかどうかの話でしか無い。
安全側はその場で終了。「例外」ならば何も書かなくてそれを実現している。

それが正しくない場合にのみ、コードを書けばいい。

47 :仕様書無しさん:2016/06/26(日) 18:57:30.89
>>45
よく読んで欲しい。
多層に重なった呼び元のどこかで、処理をするのだ。
一つのメソッドで完結せよ、という話ではない。

48 :仕様書無しさん:2016/06/26(日) 19:00:01.23
> 多層に重なった呼び元のどこかで、処理をするのだ。

俺の言い方↓に変えろやw

多層に重なった呼び元のどこかで(やる意味がある場合のみ)処理をするのだ。
やる意味がなければ処理する必要はない。
何も書かなくてもエラー処理(途中でプログラム中断)してくれるのが
例外であり、C言語などの例外がない言語との大きな違いなのだ。

49 :仕様書無しさん:2016/06/26(日) 19:01:46.73
だいたい「設定ファイルを開く」関数でも
中では設定ファイルの種類に応じて
それぞれの設定用関数を呼び出すだろ。

そうしないなら、「設定ファイルを開く」関数に何でもかんでも詰め込むという事?
それは筋が悪いな。適切な粒度ではない。

50 :仕様書無しさん:2016/06/26(日) 19:02:57.54
粒度って言ってみたかっただけかw

51 :仕様書無しさん:2016/06/26(日) 19:06:52.07
>>48
今してるのは、責任の分担の話だろ?
例外か、戻り値かに関わらないよね。

52 :仕様書無しさん:2016/06/26(日) 19:07:57.91
>>51
例外か戻り値かの話を俺がどこでしてると思ってるんだ?

53 :仕様書無しさん:2016/06/26(日) 19:15:44.44
>>52
どうでもいいけど>>44はおかしくね?
汎用的な関数って言ってるけど
何でもかんでも出来るのが汎用的なんじゃないよね?
決められた仕事だけやるのが汎用的だよね?

54 :仕様書無しさん:2016/06/26(日) 19:17:27.97
>>53
いろんなことに使えるのが「汎用的」という言葉の意味だ。

何でもかんでもできるのは「機能詰め込みすぎ」で
決められた仕事しかできないのは「専用的」というんだよ。

55 :仕様書無しさん:2016/06/26(日) 19:19:02.90
>>54
なんか腑に落ちんが、まあいい。

56 :仕様書無しさん:2016/06/26(日) 19:19:32.33
もはや誰が何を主張したいのか分からんw

57 :仕様書無しさん:2016/06/26(日) 19:24:16.36
>>55
腑に落ちないのは、お前が変なことを言ってるからだ。

「なんでもできる万能ロボット」と
「なんにでも使える汎用的なネジ」を
ごっちゃにしているからなだけだ。

58 :仕様書無しさん:2016/06/26(日) 19:24:32.92
無理やり共通処理化する初心者はあとをたたない。

59 :仕様書無しさん:2016/06/26(日) 19:26:37.98
>>57
いやいや、おまいの言い方で言えば
上手い切り口で「専用的」に作られたものが、「汎用的」に使えるんだろ。
万能ロボットが実際にはポンコツなのは判ってるよ。

60 :仕様書無しさん:2016/06/26(日) 19:26:57.51
単純化するためのモジュール分割だったのに、いろんなことができるモジュールにしてしまう事例はよくある。

逆にJavaプログラマでさえ、なんのクラス分けもないものを平然と作っていたりもする。

61 :仕様書無しさん:2016/06/26(日) 19:28:25.14
>>59
> 上手い切り口で「専用的」に作られたものが、「汎用的」に使えるんだろ。
どこにも書いてないどころか、それと正反対の事を言ってるんだが?

汎用的なのは「ファイルを開く」関数であって
専用的に作られた「設定ファイルを開く」関数ではない。

62 :仕様書無しさん:2016/06/26(日) 19:29:46.58
>>60
頭が柔らかい義務教育時代に
プログラミングの勉強をしないからそうなる。

63 :仕様書無しさん:2016/06/26(日) 19:31:51.90
>>61
おまいが上に責任を投げる事が正しいかについて
長大なレスを付けるから話がややこしくなったんだよ。

俺は業務ロジックの話をしてたんだ。

64 :仕様書無しさん:2016/06/26(日) 19:32:51.90
>>63
おや?自分の読解力のなさに気づいて
他人のせいにするのですかな?w

65 :仕様書無しさん:2016/06/26(日) 19:34:09.83
>>64
しね
あと>>44は例えが適切ではない。

66 :仕様書無しさん:2016/06/26(日) 19:35:16.16
>>65
具体的に何が問題かを言えない時点で話にならないですなw

67 :仕様書無しさん:2016/06/26(日) 19:40:23.85
>>42までは「ファイルを開く」関数の話じゃねーか

68 :仕様書無しさん:2016/06/26(日) 21:58:32.73
>>67
>>41も読もうか?

69 :仕様書無しさん:2016/06/26(日) 22:35:37.91
一気にレス増えてるわ新スレ立ってるわで吹いたんだが。
ここで熱中する人はセンスも知識も最低部類の疑いが強い
まぁ読んでないから知らんけど

70 :仕様書無しさん:2016/06/26(日) 22:36:59.61
プログラミングを知らない人がプログラミング教育をする危険性
https://wirelesswire.jp/2016/06/54228/

71 :仕様書無しさん:2016/06/26(日) 23:23:27.83
>>70
この人、2chに自分で書いてるやつだな。

文章が同じだもんw

72 :仕様書無しさん:2016/06/26(日) 23:24:46.83
>>71
どれと文章が同じなの?

73 :仕様書無しさん:2016/06/26(日) 23:26:31.21
>>72
頭の中でプログラミング

74 :仕様書無しさん:2016/06/26(日) 23:28:55.28
迷惑電話 FJネクスト ウンコ注意9評判 口コミ 悪徳・2ch.net

http://hayabusa6.2ch.net/test/read.cgi/estate/1465394964/

75 :仕様書無しさん:2016/06/26(日) 23:58:22.12
>>73
それはどの話?

76 :仕様書無しさん:2016/06/27(月) 00:37:06.75
>>75
この板でスレッドのタイトルに設計書とかが入っているスレッド

77 :仕様書無しさん:2016/06/27(月) 00:41:31.11
>>76
つまり具体的に言えないってことかな?w

78 :仕様書無しさん:2016/06/27(月) 00:43:26.60
きっとアンカし忘れただけだろうと思って優しく聞いてみたが
なんかわざとアンカするのを拒否しているようだな。
こりゃ具体的に言うまでは、こいつは答えられないと認識したほうが良さそうだw

79 :仕様書無しさん:2016/06/27(月) 00:49:10.93
自分で調べろよ。

そいつがいるスレッドはつまんないからいまは見てないんだよ。

80 :仕様書無しさん:2016/06/27(月) 00:50:40.87
>>79
その「そいつ」はここにもいるんだがw

81 :仕様書無しさん:2016/06/27(月) 00:52:28.86
横ですまんが、ここはソース貼るべきだ
でなければ逃げてるようにしか見えない

82 :仕様書無しさん:2016/06/27(月) 00:54:45.96
客から要件を聞くとプログラムが浮かぶとか言ってるやつだが、いま探したがまだ見つからない。

83 :仕様書無しさん:2016/06/27(月) 00:59:19.62
http://itest.2ch.net/test/read.cgi/prog/1448622471/

84 :仕様書無しさん:2016/06/27(月) 01:01:25.83
>>83
いやね、特定の人物の話なんだから
レス番号まで書かないと意味ないでしょ。

85 :仕様書無しさん:2016/06/27(月) 01:02:41.18
DAT落ちしてるわ。

スレッドタイトル
「いきなりコードを書くな。設計してから書け。」

86 :仕様書無しさん:2016/06/27(月) 01:07:55.66
トンファーキックで笑える人

87 :仕様書無しさん:2016/06/27(月) 08:00:35.66
無能実態派遣残業して時間報酬相場下げるな!
【知的財産と契約料金の搾取促進者ばかり】
[SI生涯損害助長SEを追放すべき]
偽装請負従犯SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの迷惑
無償プログラム提供
事前面接
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
時間外労働違反
低予備工数見積
残業見積
無料追加
学習不足
裁判苦手
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
低収入低技術
非婚離婚
鬱病早死7

88 :仕様書無しさん:2016/06/27(月) 12:45:56.24
>>7
> アプリ屋にとっては例外は標準だけで数十個
わざわざ複雑にして自慢するとかバカじゃね?

89 :仕様書無しさん:2016/06/27(月) 12:49:04.20
例外出たから工場止めるよ。

が許されたなら幸せだったのにな。

90 :仕様書無しさん:2016/06/27(月) 14:47:57.39
センスある人は競技プログラミングでも良い成績になる

91 :仕様書無しさん:2016/06/27(月) 20:42:50.05
>>89
> 例外出たから工場止めるよ。

それは例外をキャッチしなかったら
そうなるって話?

例外をキャッチするから工場は止まらないよね。
これは例外の利点の一つ。


例外を使わないと、エラーが起きても工場は止まらないとか
なって挙句の果てに爆発起こしたりしそうだねw

92 :仕様書無しさん:2016/06/27(月) 20:43:57.97
>>88
例外じゃなくてもエラーの数はこれぐらいあるだろ?
エラーコード表見てみ。

93 :仕様書無しさん:2016/06/27(月) 21:38:25.96
>>92
ないよ。

94 :仕様書無しさん:2016/06/27(月) 21:39:05.20
だいたい、なんでアプリがシステムレベルのエラーを意識しないといけないんだ。

95 :仕様書無しさん:2016/06/27(月) 21:39:31.62
成功したかどうかがわかればいい。

96 :仕様書無しさん:2016/06/27(月) 22:11:52.20
>>93
可哀想にw

97 :仕様書無しさん:2016/06/27(月) 22:48:23.29
>>96
あなたが一番可哀想な感じがします
自分が知る範囲だけで、他のシステムも同様と決めつけてるところがね

98 :仕様書無しさん:2016/06/27(月) 23:00:56.10
>>97
自分が知る範囲で無いよって言ってるわけかw

99 :仕様書無しさん:2016/06/27(月) 23:01:29.45
Oracleのエラーコード表見てみ?

100 :仕様書無しさん:2016/06/27(月) 23:23:52.55
SQLエラーのことか?
インジェクションされるようなアプリ作るなよ

101 :仕様書無しさん:2016/06/27(月) 23:27:00.50
>>100
流石にそれは無知すぎw

102 :仕様書無しさん:2016/06/27(月) 23:35:41.52
つか、エラーと例外は別モンだよな

103 :仕様書無しさん:2016/06/27(月) 23:44:59.36
違い? こんなんでどうかね?
例外のほうが幅広い。

http://mameratta.tumblr.com/post/6282752670/%E4%BE%8B%E5%A4%96%E3%81%A8%E3%82%A8%E3%83%A9%E3%83%BC%E3%81%AE%E9%81%95%E3%81%84

例外:

「対応しない/できない/許容しない/責任範囲外」等の意思を実装で表明するもの。
例外を投げるのは、自分が対応しない/できない処理や、許容しない処理、実行環境や別モジュールなどの責任範囲外で失敗した通知など。
通常発生しない/発生してはいけない処理。例えばstd::logic_errorとか。そこが呼ばれること自体がおかしいなど。
対策をとらない/とる気がない処理。正しい前提で処理をし、異常系を処理しないなど(std::invalid_argumentとか)
必ずしもエラーとは限らない(が、現実的には大半がエラー)。割り込みや中断、タイムアウトなどは、エラーでなくても例外的と言えることも。

エラー:

想定しうる処理失敗/異常系処理で、対応の用意/意図/可能性があったもの。
逆に言うと、自分が受け付けて処理を試みた上で完了できなかったもの。

104 :仕様書無しさん:2016/06/28(火) 06:20:41.84
>>103
Javaだと逆なんだよな。

言葉の定義は難しいよ。

105 :仕様書無しさん:2016/06/28(火) 08:10:03.64
【主な偽装請負従犯SEの作業】
[技術不要の使い捨てスキル]
コマンド
データ > ロジック
簡単ロジック
大量データ
SE適性不要
IT資格不要
大卒資格不要
文科系対象
体育系対象
商業系業種
業務系処理

[業務ソフト作り捨てソフト]
ノンプログラミングツール
フレームワーク
COBOL
VB
.net
Java
Web
DB
ERP
SAP1

106 :仕様書無しさん:2016/06/28(火) 12:19:50.80
>>103
エラーを例外でぶん投げてくるのが間違いの元。

107 :仕様書無しさん:2016/06/28(火) 12:50:08.93
日本語の文章がうまい人はプログラムのセンスも高い。

108 :仕様書無しさん:2016/06/28(火) 19:41:40.39
それはプログラムじゃなくてコメントな

109 :仕様書無しさん:2016/06/28(火) 20:38:56.08
>>108
はあ?

110 :仕様書無しさん:2016/06/28(火) 20:39:59.17
言葉で説明できないロジックなんて特殊なアルゴリズム以外にないだろ。

111 :仕様書無しさん:2016/06/28(火) 20:45:05.00
プログラムセンスあんまり関係ないかもだけど、ログの開始位置はどっちがいいと思う?
自分的には一連の処理が始まるタイミングで
開始ログ〜チェック処理〜実処理〜リソースの破棄〜終了ログ
なんだが、先輩はチェック処理が全部終わって実処理が始まったタイミングと終わったタイミングでログを吐くべきって言ってて、
とりあえず言うとおりにしたけどしっくりこなくて。
処理のくくりが違うんだろうか。

112 :仕様書無しさん:2016/06/28(火) 20:54:31.18
>>109
日本語がうまくてセンスがよいのはコメント
プログラムコードは関係無い
コードとコメント両方が上手い人は
コーディングセンスと日本語のセンスの両方を持ってる

113 :仕様書無しさん:2016/06/28(火) 21:15:18.80
>>112
前後で矛盾してないか?

114 :仕様書無しさん:2016/06/28(火) 21:16:14.59
>>111
それはたぶんコボラー

115 :仕様書無しさん:2016/06/28(火) 21:16:57.85
なんとか処理部とか言い出すのはコボラー

116 :仕様書無しさん:2016/06/28(火) 21:18:05.03
処理の最初と最後が分からなければ、意味がない。

117 :仕様書無しさん:2016/06/28(火) 21:24:32.82
>>111
場合によるけど、無意味なログが出まくるのは鬱陶しい
後でログを確認したときに、中身の無い開始終了が延々と続いてるとか

118 :仕様書無しさん:2016/06/28(火) 21:26:39.24
なんとか処理部なんて誰も言ってない。
処理という文字を見ただけで処理部に
見えてしまう人はコボラーw

119 :仕様書無しさん:2016/06/28(火) 21:37:34.95
>>111
チェックの内容による。

例えばユーザーが入力したデータに対するチェックは基本的にログに取らない。
例えば「名前は必須入力です」みたいなエラーを出すためのチェック

それに対して関数の引数としてありえないものを渡した(要するにバグ)を
検出するためのチェックであれば、ログに取る。
この場合は、チェックしてありえない引数であることを検出したら
例外として送出する。あとは例外の共通処理部分でログに記録される。

120 :仕様書無しさん:2016/06/28(火) 21:41:29.99
構成の良い綺麗な文章を書ける人はプログラムもセンスあるよね

121 :仕様書無しさん:2016/06/28(火) 21:56:09.30
普通の文章で、英数字やスペース、括弧などを全角半角入り混じって書いちゃう人のコードは信用しないことにしている。

122 :仕様書無しさん:2016/06/28(火) 22:03:50.92
>>115
なるほど、そういう用語はコボラー寄りなんだね
知らんかったわ

123 :仕様書無しさん:2016/06/28(火) 22:04:40.13
>>121
普通の文章って何さ

124 :仕様書無しさん:2016/06/28(火) 22:07:36.73
>>119
ユーザーの入力だからかもしれません。
納得しました。
自分のタイミングだとファイルがないときとかフォルダがないときかアクセスできないときとかでログが出るから適切ではないかもしれません。
例外処理は共通じゃなく出たとこでキャッチしてログに吐いて終わる感じです。

125 :仕様書無しさん:2016/06/28(火) 22:08:21.65
>>121
ドキュメントの半角カッコをリーダーに全角カッコに書き換えられていましたがこの場合はどうなりますか

126 :仕様書無しさん:2016/06/28(火) 22:09:09.65
>>116
そう思ったのですが認識が違ったみたいです。

127 :仕様書無しさん:2016/06/28(火) 22:10:29.36
>>111みたいなSIer的で原始的な事ってまだやってるんだね(驚き)

AOPやそれに似た感じの手法でログ吐くことに慣れちゃうと
もう、そんな事やれって言われたら、辞めますわw

128 :仕様書無しさん:2016/06/28(火) 23:12:25.08
> AOPやそれに似た感じの手法でログ吐くことに慣れちゃうと
具体的にどの言語でどのライブラリ(フレームワーク?)の
ログを吐く方法使ってるの?

ぶっちゃけAOPは流行ることなく消えた技術の一つだと
考えているのでね。

129 :仕様書無しさん:2016/06/28(火) 23:32:38.38
>>113
どこ?

130 :仕様書無しさん:2016/06/28(火) 23:34:34.39
>>126
COBOLだとソースコードに処理の分類がある。

コボラーにプログラムを書かせるとあまり意味のないコメントを書き出す。

131 :仕様書無しさん:2016/06/28(火) 23:34:53.04
そうだよなあ
AOPと大層な名前付けても、ログ吐く以外に使い道がなあ。。

132 :仕様書無しさん:2016/06/28(火) 23:36:10.67
>>129
後者に前者が含まれているだろ?

133 :仕様書無しさん:2016/06/28(火) 23:48:36.18
>>130
処理の分類とは起承転結で分かれてるみたいな感じですか??

134 :仕様書無しさん:2016/06/28(火) 23:55:05.00
>>132
はあ?

135 :仕様書無しさん:2016/06/29(水) 00:14:52.07
>>133
COBOLはそういう区分がある。

COBOLプログラムの基本構造

COBOLのプログラムは、次の4つのDIVISIONをこの順番で記述するのが基本となっている。

IDENTIFICATION DIVISION……見出し部ENVIRONMENT DIVISION……環境部DATA DIVISION……データ部PROCEDURE DIVISION……手続き部

136 :仕様書無しさん:2016/06/29(水) 00:16:34.10
>>134
コメントがうまい人の一部の集合は、コメントもコードもうまい人の集合と重なってるよね?

137 :仕様書無しさん:2016/06/29(水) 00:32:54.76
ログは出しすぎかなと思っても、何かあったときに原因を突き止めるのに
必要だから出しておいた方がいい。ログの出力が少なすぎるとログの
埋め込みからやらないとならないからになって対応が遅れるから。

中にはログを出すのが恥だとでも思ってるのか、頑なにログ出力する
コードを書かない奴がいるけど、そういうやつは邪魔だから早いうちに
矯正しておいた方がいい。

あとはオレオレロガーを使うのではなく、有名どころのログフレームワークを
使うこと。

ログの出力しすぎかなと思っても今だとfluentdみたいので、集約したり
ファイル分けたりなんかは簡単だから。 ログがなくて困ることはあっても
ログがあって困るのはログの生存期間を悩むくらいだからね。

138 :仕様書無しさん:2016/06/29(水) 00:35:53.41
>>135
レビュー後の直しがそんな感じだったのでコボラーなのかもしれません
とりあえずは言うとおりにしておきます
今更ですが、言語はc#でした

139 :仕様書無しさん:2016/06/29(水) 00:38:29.90
>>137
ログで必要な情報って、運用に携わってないと中々わかんないんだよね
プログラムの動作を追えるのも必要だけど
誰が何をやったかというのも聞かれる事あるからね

140 :仕様書無しさん:2016/06/29(水) 00:41:20.58
>>137
そう思って共通部品でスタックトレース含めて出力できるようにしたんですがダメらしくて、ため息をつかれました。
各メソッドで発生時点で例外ごとにキャッチして、その時点で書き出すように指示されたので今はそのように実装してます。
例外ごとになにがだめだったか画面にメッセージボックスで出すようにしたのでエビデンスで発生した例外のあたりはつく感じになってます。

141 :仕様書無しさん:2016/06/29(水) 00:43:26.14
fluentdはログの集約ばかり注目されるけど
本当に良い所は、ディスクIOとの間に挟まるバッファになる所だと思う。

一旦メモリに吐き出すので、IOにプログラムが引っ掛かることが無い。
マルチスレッドで直接ファイルに吐くとありがちな、競合、ログの消失も無い。

142 :仕様書無しさん:2016/06/29(水) 00:50:23.52
ちなみにlog4系は嫌いだ
マルチスレッドに対応してなかったりするから

143 :仕様書無しさん:2016/06/29(水) 02:08:38.39
A応P?

144 :仕様書無しさん:2016/06/29(水) 04:02:04.51
ログファイルはプロセス、スレッド単位でかぶらないように、また時間をファイル名に入れておく。

ログファイルなんてただのテキストだから大量に出てもたいしたことない。

無駄にループ内で同じメッセージを出すのはアホだから、エラーメッセージとエラー発生時のデータ、操作、時間が分かれば十分。

ログファイルは定期的に自動で削除すればいい。

145 :仕様書無しさん:2016/06/29(水) 04:05:30.76
たかがログファイルくらいで変なもの使う必要ないよ。

外国人が出すようなログファイルは見づらいでしょ?

日本人と違って不親切なんだよな。

146 :仕様書無しさん:2016/06/29(水) 08:21:11.19
たかがログファイルなんて言えちゃうような人がセンス無い人なんだろうな。

147 :仕様書無しさん:2016/06/29(水) 08:36:10.86
スレッド間通信とかログファイルに出すと数秒で50Mとかなって困る

148 :仕様書無しさん:2016/06/29(水) 09:47:25.68
年収1,000万円以下の低レベルSEへ

SEの低生涯収入と短勤続年数の対策を考えろよ!
相場下がって迷惑だから交渉するか作業減らせ!
生産下がって迷惑だから技術は報酬で評価しろ!

[推定平均生涯収入]
100万/月 3億5,000万円以上(大卒サラリーマン上位レベル)
90万/月 3億円以上(大卒サラリーマン平均レベル)
80万/月 2億5,000万円以上(大卒サラリーマン下位レベル・高卒サラリーマン上位レベル)
70万/月 2億円以上(高卒サラリーマン平均レベル)
60万/月 1億5,000万円以上(高卒サラリーマン下位レベル)
50万/月 1億円以上(フリーターレベル)
40万/月 5,000万円以上(パートレベル)

149 :仕様書無しさん:2016/06/29(水) 12:06:13.81
>>146
キミの経験がないからそう思うのかもよ。

150 :仕様書無しさん:2016/06/29(水) 12:15:26.46
>>147
他のチームから殴られないかそれw

151 :仕様書無しさん:2016/06/29(水) 12:40:29.83
50Mはないけど、初期化処理だけでトレースがあふれてて、
一個前の実行時点のログが全く影も形もない、そんなのばっか。
関数の出入りを全部取る!とかバカだろおまえ...

152 :仕様書無しさん:2016/06/29(水) 13:29:48.11
取るのはいいんだけど、後で簡単に検索出来ないとな

153 :仕様書無しさん:2016/06/29(水) 13:49:09.17
>>150
一応、ログを種類分けして任意で表示させれるようにした
デバッグ中はそれでいいけど、予測不能のバグの場合はしっかりログが残ってないぜ

154 :仕様書無しさん:2016/06/29(水) 13:57:34.70
>>153
おまいの理屈だと、インサーキットエミュレータでCPU動作の全ステップを記録してないとバグは取れないと言う事になるが、そんな事しないだろ?

155 :仕様書無しさん:2016/06/29(水) 14:41:09.08
ログ出力できないような異常時は直前の処理がわかれば問題ない。

156 :仕様書無しさん:2016/06/29(水) 15:40:20.42
発生条件さえ判明すれば何とかなる。
再現性のないバグが発生すると死ぬ。

157 :仕様書無しさん:2016/06/29(水) 17:45:38.85
スタックトレース見りゃだいたい判るだろ

センスがないヤツはログの見方も分かってない

158 :仕様書無しさん:2016/06/29(水) 18:26:35.93
それJavaの話?

159 :仕様書無しさん:2016/06/29(水) 18:59:18.58
111のログについて質問したものです。
もう一つ質問いいでしょうか?
今日インスタンス生成のタイミングについても修正がありました。
1メソッド内でしか使用しない変数で、特に何度も初期化をしなくてもいいクラスを実体化するのにコンストラクタ内で初期化を行いました。
そのタイミングを、メソッド内で、変数の定義も初期化も行ってほしいと指示されました。
何度も呼ばれる処理ですし、一度実体化すればそれを使い回しておけると思いそうしたのですが、メソッド間で使用しない変数はフィールドにしてほしくないらしいです。
スコープを考えるのであればその方がよいのでしょうか?

160 :仕様書無しさん:2016/06/29(水) 19:03:57.41
何度も呼ばなくていいのか何度も呼ばれるのかどっちよ。

161 :仕様書無しさん:2016/06/29(水) 19:06:32.61
>>159
オブジェクトのライフタイムは出来るだけ狭いスコープでってのは、割と常識。

162 :仕様書無しさん:2016/06/29(水) 19:16:15.48
画面操作に伴う処理なのですが、ボタン押下の度にメソッドは呼ばれます。
変数は特に引数もないので初期化自体は一度で大丈夫です。
ほかのインスタンスはメソッド内で定義してます。
それだけは頻繁に呼ばれるので一度実体化しておいた方が実行効率としてはいいのかなと思っていました。
if文で囲んでnullの場合だけ生成するようにするのだといかがでしょうか。
一応メソッドの最後でdisposeはします。

163 :仕様書無しさん:2016/06/29(水) 19:16:33.16
>>159
それは先輩が正しい。

164 :仕様書無しさん:2016/06/29(水) 19:17:11.05
メソッド内での話です。
すみません。

165 :仕様書無しさん:2016/06/29(水) 19:48:05.29
>>159
素直に先輩の言うこと聞いとけ
そして疑問に思う事はここで聞かずにその先輩に聞いた方が良い

166 :仕様書無しさん:2016/06/29(水) 19:55:40.21
>>165
聞いたんですが答えてもらえなくて言うとおりにすればいいとのことだったので、すみません。

167 :仕様書無しさん:2016/06/29(水) 20:12:20.94
>>166
プログラマの「〜の方が効率が良いと思った」程、信用できないものはないってのも、割と常識。

シンプルな構成に保つのが第一。
実際に何か問題が起きたら、まず実測。
思い込みで作ったものは、後でみんなに迷惑かけるからね。

168 :仕様書無しさん:2016/06/29(水) 20:15:14.24
>>162
スレ前後しちゃうけど、そういうのを早期の非最適化って言うらしいぞ。
実際には何の問題もないのに、思い込みで無駄に変な作りにして、後で当時の意図がわからず困るという、アンチパターン。

169 :仕様書無しさん:2016/06/29(水) 20:24:51.03
>>159
これはグローバル変数の問題と同義。
自分で書いている通り、スコープを考えるのであれば、その方が良い。

170 :仕様書無しさん:2016/06/29(水) 20:31:01.17
>>169
自分でもあまりよくないのはわかっていたんですが、一度しか実体化しなくていいものを何回も実体化するのには抵抗があってこのような形にしてました。
スコープも考慮したやり方を調べてみます。
ありがとうございました。

171 :仕様書無しさん:2016/06/29(水) 20:36:06.39
初期化が重くなければローカルスコープで構わないけど
重いとかプロパティ保持が前提なら1メソッドだろうがクラスメンバ化
少しでも処理速度を稼ぎたい組込やゲームなんかは、見た目以上に効率化だな

172 :仕様書無しさん:2016/06/29(水) 21:46:58.28
>>142
log4j系ってlogbackも含むの?

173 :仕様書無しさん:2016/06/30(木) 00:53:02.11
int等の組込型なら初期化のコストは無視できるレベルだし、その変数が特定
メソッドでしか使われないなら、メソッド内のローカル変数にすべきだろう。

ローカル変数であれば、x86系CPUなら1命令でイミディエイト値をPUSHできる
し、スタック上の変数は、SP+固定オフセットでアクセスできる。ENTER/LEAVE
命令を使えば、複数のローカル変数領域の確保と開放を一気にできる。

クラスメンバの場合、CXレジスタなどにthisポインタを保持しての相対アク
セスになるが、そのメンバ関数はマルチスレッドでは呼べない。

複数のメソッドから更新・参照されていれば、排他処理を追加していないと、
それらメンバ関数同士もマルチスレッドでは呼べない。

但し、同じクラスオブジェクトの全てのインスタンスに対して共通の定数など
であれば、const型のstatic メンバとして宣言すべき。コンストラクタで
初期化する必要もない。

174 :仕様書無しさん:2016/06/30(木) 01:14:21.81
すみません、ただのprocessクラスです。
プロパティは設定しますがメソッド内で定義します。

175 :仕様書無しさん:2016/06/30(木) 01:25:38.31
>>173
そういうのは断定できないことだから、ある程度までにしてやめた方がいい。

いまのOS、CPU、その他ハードウェアでは本当にそうかどうかを証明できない。

176 :仕様書無しさん:2016/06/30(木) 08:01:30.70
年収1,000万円以下の低レベルSEへ

SEの低生涯収入と短勤続年数の対策を考えろよ!
相場下がって迷惑だから交渉するか作業減らせ!
生産下がって迷惑だから技術は報酬で評価しろ!

[推定平均生涯収入]
100万/月 3億5,000万円以上(大卒サラリーマン上位レベル)
90万/月 3億円以上(大卒サラリーマン平均レベル)
80万/月 2億5,000万円以上(大卒サラリーマン下位レベル・高卒サラリーマン上位レベル)
70万/月 2億円以上(高卒サラリーマン平均レベル)
60万/月 1億5,000万円以上(高卒サラリーマン下位レベル)
50万/月 1億円以上(フリーターレベル)
40万/月 5,000万円以上(パートレベル)

177 :仕様書無しさん:2016/06/30(木) 14:39:07.93
dispose必要なのに?

178 :仕様書無しさん:2016/06/30(木) 22:58:33.52
>>144
> ログファイルなんてただのテキストだから大量に出てもたいしたことない。
テキストだからこそ、実行性能に影響出ること結構あるぞ

179 :仕様書無しさん:2016/07/01(金) 00:15:19.05
テキストって最も容量効率悪いはずなんだが・・・

180 :仕様書無しさん:2016/07/01(金) 01:05:23.15
>>144
> 無駄にループ内で同じメッセージを出すのはアホだから、エラーメッセージとエラー発生時のデータ、操作、時間が分かれば十分。

本当にそうかね? それがマルチスレッドで動いていれば
スレッド番号もわかったほうがいいだろう?
forkとかを考えればプロセスIDもほしいだろう?
複数のユーザーがログインするサーバーならば
ユーザー名がわかったほうがトラブル解決に役に立つぞ

181 :仕様書無しさん:2016/07/01(金) 01:27:02.81
catとgrepで確認できるから実用的だよ。

182 :仕様書無しさん:2016/07/01(金) 01:29:55.61
スレッド番号やプロセスIDが判っても、ログを開いた時点でそのスレッドや
プロセスは既に存在していないと思うが? それらに依存する再現性がある
というなら話は別だが、本質的に無駄な情報だろう。

183 :仕様書無しさん:2016/07/01(金) 01:32:51.16
あんなこといいなできたらいいな vs 実用的

184 :仕様書無しさん:2016/07/01(金) 02:17:36.07
>>181
cat必要?

185 :仕様書無しさん:2016/07/01(金) 07:54:36.82
>>182
それらが無ければ一連の動作が繋がらんだろ。

186 :仕様書無しさん:2016/07/01(金) 07:57:23.84
運用した事ない人はログの活用法のイメージが湧かないんだよね。
だからただスタックトレース出す話に終始する。

187 :仕様書無しさん:2016/07/01(金) 08:01:58.42
さすがトラブル対策ばかりやってる人の言うことは違うな。

188 :仕様書無しさん:2016/07/01(金) 09:43:11.33
プロセスIDはあった方がいいぞ。
同じ通過ログが、複数あった時とか至極便利
つか、無いと追えない。

189 :仕様書無しさん:2016/07/01(金) 10:22:00.38
そんな障害を起こすプログラムを作る方がおかしいけどな。

問題箇所の特定ができないシステムの仕様もおかしい。

つまり設計がおかしい。

190 :仕様書無しさん:2016/07/01(金) 11:41:59.83
「アップルにアイデア盗まれた」 1兆円超の賠償求め米国男性が提訴
http://headlines.yahoo.co.jp/hl?a=20160701-00000012-jij_afp-int

191 :仕様書無しさん:2016/07/01(金) 11:45:00.24
>>189
障害がテスト環境で再現出来るんなら、別にログは必要ないんよ。
ただ、報告者の報告通りやっても再現しないとか、報告者の
勘違いだったなんて割とよくあるし。本場環境だと起きて、テスト
環境だと起きないなんてのもざらだし。報告が無いからと言って
放置してたら、使われなくなるなんてのもあるし。
ログがあれば直せてなくても、既知の問題として対処したりも
できるし、開発だけして、はいさようならな人には理解出来ない
だろうけどね。

192 :仕様書無しさん:2016/07/01(金) 11:46:34.47
>>191
それはプログラムの問題ではないだろ。

プログラムの問題ではないことを証明するためにログファイルは存在する。

193 :仕様書無しさん:2016/07/01(金) 11:49:03.21
なんか問題の切り分けがおかしい人がいるけど、最近の現場ってこんなのばかりだな。

経験者が去っていくからレベルがなかなかあがらない。

194 :仕様書無しさん:2016/07/01(金) 12:26:17.95
問題がないのに問題の切り分けだけがあるという不思議w

195 :仕様書無しさん:2016/07/01(金) 12:28:55.15
>>194
ここでいってるやつらは自分のプログラムのことを言ってたり、環境のことを言ってたりと、初心者すぎるんだよ。

196 :仕様書無しさん:2016/07/01(金) 12:32:34.33
環境のログファイルを見なきゃいけない状況を作り出している方が悪い。

まあ外国人に作らせたり、環境自体が外国製だから変な問題が発生するんだが。

197 :仕様書無しさん:2016/07/01(金) 12:41:34.82
>>182
個々のスレッドがどう動いたかがわからないと何が起きたのかすらわからないだろ

198 :仕様書無しさん:2016/07/01(金) 12:44:49.37
>>196
プログラミングしかやったことない人らしい発言ですね。

199 :仕様書無しさん:2016/07/01(金) 12:52:09.83
>>198
すさまじい誤解w

よほどひどいシステムしか見たことがないんだろうな。

200 :仕様書無しさん:2016/07/01(金) 12:54:05.15
>>198
おまえ、まえも同じレスしてるよな?

それしかないのか?

201 :仕様書無しさん:2016/07/01(金) 16:46:44.08
>>197
スレッド番号やプロセスIDが判ったら、スレッドがどんな動きをしたか
判るんだ。 現場の血文字で真犯人が判っちゃうコナン君でちゅか?

そんな下らん情報より、エラー出したソースのファイル名とソース行番号
くらいレガシー言語のCでもマクロで一発で出せるだろ。

運用とか構築やってる連中(特にインフラ系)って、意識だけ高くて表面的な
知識だけでレベルが低い印象。

202 :仕様書無しさん:2016/07/01(金) 17:09:10.88
>>201
エラーになるような簡単な問題ならいいですねー

203 :仕様書無しさん:2016/07/01(金) 17:11:36.01
インフラ屋って理由のあまりない設計、構成が多いからな。

理屈がないやつが多い。

そうしてみたかっただけとか多くてびっくりする。

204 :仕様書無しさん:2016/07/01(金) 17:12:21.17
>>202
だから、それは作ったプログラムの問題ではないだろうか?

205 :仕様書無しさん:2016/07/01(金) 17:17:03.64
>>204
自分が作ったプログラムに一切不具合はないと言い切れるんだ。
おじさん、そんな自信はないから万が一の時に原因をトレースできるように
ログ出しちゃうなぁ。

206 :仕様書無しさん:2016/07/01(金) 17:40:42.74
自分で作ったプログラムで発生した事象で原因わからんとか
センスないから職を変えた方が世のためだな
他人のモジュール呼ぶにしても想定外の返却値が戻された箇所くらいはわかるはず

207 :仕様書無しさん:2016/07/01(金) 17:57:49.84
迷惑電話 FJネクスト ウンコ注意9評判 口コミ 悪徳・2ch.net

http://hayabusa6.2ch.net/test/read.cgi/estate/1465394964/

208 :仕様書無しさん:2016/07/01(金) 18:07:12.66
>>205
自分が作った範囲ではすべてのことを想定して作るのが普通だろうが?

209 :仕様書無しさん:2016/07/01(金) 18:08:27.08
>>208
へー

210 :仕様書無しさん:2016/07/01(金) 18:11:09.80
あたりまえだが、初心者はこれができない。

それは誰でも最初からできたわけではないからね。

なんかログ出力派なのに逆のことを言われてるけどなんなんだこの流れ。

211 :仕様書無しさん:2016/07/01(金) 18:11:51.28
>>208
電源引っこ抜かれたことも想定して設計するよな

212 :仕様書無しさん:2016/07/01(金) 18:20:35.18
>>211
当然だろ。

213 :仕様書無しさん:2016/07/01(金) 18:22:10.95
サーバー(ノード)が突然、落ちることはあるからな。

初心者は再起動のことも考えてなかったりするからやっかい。

214 :仕様書無しさん:2016/07/01(金) 18:52:05.72
>>201
もしかして落ちた瞬間しかログ出さない前提で話してる?

215 :仕様書無しさん:2016/07/01(金) 18:55:17.52
>>210
>それは誰でも最初からできたわけではないからね。

最初から完璧には無理かも知れんが
基本的に最初できないヤツは、ずっとできない

自分で作ったものが理解できてないのは
責任感とか論理的思考力が足りてないだけなので、経験ではなく資質の問題だ

216 :仕様書無しさん:2016/07/01(金) 19:21:38.18
そろそろセンスある人求む

217 :仕様書無しさん:2016/07/01(金) 19:26:47.50
Windowsで育った人はログ出さない印象

218 :仕様書無しさん:2016/07/01(金) 19:43:02.81
>>216
暑いから扇子はいつも持ち歩いてる

219 :仕様書無しさん:2016/07/01(金) 20:31:35.44
>>216
む求人

220 :仕様書無しさん:2016/07/01(金) 20:34:55.60
>>217
たぶんね、画面まわりしか作ったことしかないと出さないかもしれない。

そういうやつがバッチ処理を作るとなんのログもないものを作ってトラブルに対処できない。

何ヶ月か前に話した20代後半のやつがそうだった。

221 :仕様書無しさん:2016/07/01(金) 20:35:32.71
どれもセンスねえレスだなw

222 :仕様書無しさん:2016/07/01(金) 20:39:30.78
>>221
どれもセンスねえレスだなw

223 :仕様書無しさん:2016/07/01(金) 20:50:24.88
>>217
お前さんかわいそうな世界で生きてるな

224 :仕様書無しさん:2016/07/01(金) 23:19:52.23
イベントビューアーとか見たこと無いんだろうな

225 :仕様書無しさん:2016/07/01(金) 23:43:16.89
>>220
画面周りこそログだろ。
デバッガ使うと挙動が変わるし。

226 :仕様書無しさん:2016/07/01(金) 23:45:42.01
>>201
コナンはさ、死体があるから仕事できるんだよ。
血文字でも遺書でも大差ない。基本的に状況は変化しないから。

227 :仕様書無しさん:2016/07/02(土) 00:04:21.46
>>225
デバッガ?

プロはデバッガはあまり使わない。

228 :仕様書無しさん:2016/07/02(土) 00:05:53.49
>>227
メモ帳一択www

229 :仕様書無しさん:2016/07/02(土) 00:09:28.63
>>228
笑うところじゃないよ。

230 :仕様書無しさん:2016/07/02(土) 00:11:55.41
>>224
Windows界隈の人って見ないよね

231 :仕様書無しさん:2016/07/02(土) 00:14:23.04
イベントログは証拠隠滅のためにも使える。

232 :仕様書無しさん:2016/07/02(土) 00:14:33.40
>>224
スレッド単位のログみたいな雰囲気で出してたら
ロストしまくるだろ。

233 :仕様書無しさん:2016/07/02(土) 00:15:26.60
>>232
ものによるだろ。

どんなの想定してんだよ。

234 :仕様書無しさん:2016/07/02(土) 00:22:22.64
>>230
お前の世界ではな

235 :仕様書無しさん:2016/07/02(土) 00:45:54.19
>>220
むしろエンド側しかやったことなかったからフロントの仕事したときに価値観が合わなくて疑問に思ってました。
そういうことだったんですね。

236 :仕様書無しさん:2016/07/02(土) 01:15:12.22
バックエンドとフロントエンドね。

237 :仕様書無しさん:2016/07/02(土) 03:52:21.55
SEX用語かと思ってた。

238 :仕様書無しさん:2016/07/02(土) 08:37:32.64
フロントエンドがバックエンドを、乱暴に扱うのはよくないよな
同性の場合は特に、色々と問題が出てくる

239 :仕様書無しさん:2016/07/02(土) 09:30:15.18
>>236
素で間違えました。
ありがとうございます。

240 :仕様書無しさん:2016/07/02(土) 22:28:34.78
Windowsで育ってフロントエンドメインだったけど
確かにバックエンド担当にしたときログ残そうとしないな
もちろん残すんだが何残すべきか考えるの面倒っていうか

241 :仕様書無しさん:2016/07/02(土) 23:46:39.21
プログラマーとしてだましだまし5年以上やってきたけど
体系的に学んだことがないから
新しい職場では全く通用せず残業のオンパレード
このままじゃやべーな

242 :仕様書無しさん:2016/07/03(日) 06:28:56.42
まず全員と仲良くするべし
たとえ性格が合わなかったり真剣に仕事をやらない人とでも。
仲良くなったぶんだけ質問が許される。
質問攻めしても対応してくれるなら大親友だ

243 :仕様書無しさん:2016/07/03(日) 08:18:16.19
仲良くなれば、今後仕事を紹介されるかもしれないしな。

仲良くなれないと、どんなに技術があろうが仕事は振ってこない。

244 :仕様書無しさん:2016/07/03(日) 08:24:04.17
アホな質問が許されるのは、相手もアホな場合のみ
俺なら、あいつやべぇぞ、ってリーダーにチクるわ

245 :仕様書無しさん:2016/07/03(日) 08:34:36.65
あ、もちろんアホじゃない質問なら真面目に回答する
むしろ人に教えるのは好き

246 :仕様書無しさん:2016/07/03(日) 09:28:45.13
今技術が低くても前向きに勉強する人は応援する。
技術を軽く見てなめてる奴は潰す。

247 :仕様書無しさん:2016/07/03(日) 09:37:56.03
>>246
お前潰されんぞ

248 :仕様書無しさん:2016/07/03(日) 13:21:44.10
技術屋の家族かわいそう

技術ない方が寿命と収入高い

技術下げるか収入上げろ!

放送・商社・銀行・公務 > 製造・化学・通信・情報

2014年度有価証券報告書より
伊藤忠商事 1,395万円(41.5歳)
三菱商事  1,376万円(42.6歳)
三井物産  1,361万円(42.4歳)
丸紅    1,306万円(41.5歳)
住友商事  1,301万円(42.8歳)

http://m.finance.yahoo.co.jp/stock/fundamental?code=4676.T
3

249 :仕様書無しさん:2016/07/03(日) 17:05:51.36
>>248
コピペにレスつけるのもあれだが、
確か商社マンって退職後の寿命が短いんじゃなかったかな?

250 :仕様書無しさん:2016/07/03(日) 17:24:26.92
>>249
SE寿命は退職前

251 :仕様書無しさん:2016/07/04(月) 23:57:58.56
>>243
きもい

252 :仕様書無しさん:2016/07/05(火) 12:36:01.91
幾多の難関をくぐり抜け仕事を勝ち取ってきた歴戦のアナル

253 :仕様書無しさん:2016/07/06(水) 07:51:26.85
【主な偽装請負従犯SEの作業】
[技術不要の使い捨てスキル]
コマンド
データ > ロジック
簡単ロジック
大量データ
SE適性不要
IT資格不要
大卒資格不要
文科系対象
体育系対象
商業系業種
業務系処理

[業務ソフト作り捨てソフト]
ノンプログラミングツール
フレームワーク
COBOL
VB
.net
Java
Web
DB
ERP
SAP5

254 :仕様書無しさん:2016/07/06(水) 21:43:57.67
東大卒の新人には勝てないと思った

255 :仕様書無しさん:2016/07/06(水) 21:49:00.83
何に勝てないって?

256 :仕様書無しさん:2016/07/06(水) 21:54:26.08
新人のアナルには勝てない

257 :仕様書無しさん:2016/07/10(日) 00:14:25.27
http://hayabusa6.2ch.net/test/read.cgi/pc2nanmin/1439353617/216
        ↑  ↑  ↑ 

258 :仕様書無しさん:2016/07/11(月) 08:16:33.12
無能実態派遣残業して時間報酬相場下げるな!
【知的財産と契約料金の搾取促進者ばかり】
[SI生涯損害助長SEを追放すべき]
偽装請負従犯SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの迷惑
無償プログラム提供
事前面接
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
時間外労働違反
低予備工数見積
残業見積
無料追加
学習不足
裁判苦手
対人障害
健康障害
孤独死7

259 :仕様書無しさん:2016/07/11(月) 18:01:44.98
ほんとにできる奴って凄い事を普通にやって凄い事の様に見せないと思う

260 :仕様書無しさん:2016/07/11(月) 20:02:22.91
別に凄い事じゃなくたって
普通の事を普通にこなせてるだけでも凄い事ですよ

261 :仕様書無しさん:2016/07/11(月) 20:29:32.32
>>259
は?凄いことをやってりゃできる奴じゃん

出来もしないのに口弁慶は山ほどいるけどな

262 :仕様書無しさん:2016/07/11(月) 20:29:52.61
できる奴は、初めからできる。
理屈じゃない、そういう世界。
努力は無駄だよ。

プログラム構造のイメージを作りながらコードを読む事なんて
訓練してもできるようにならないからね。

263 :仕様書無しさん:2016/07/11(月) 20:31:41.57
小説を読めば情景が広がる。それと同じくらいの読解力くらい持てよ。

264 :仕様書無しさん:2016/07/11(月) 20:37:29.06
小説を読んで見える情景は千差万別だけどな

265 :仕様書無しさん:2016/07/11(月) 20:47:41.95
無能ITドカタへ

契約外の作業期日は断れ!
時間外労働違反はするな!
生産技術低すぎなんだよ!

無能残業者は優秀なSEに迷惑
無能残業者は共働きSEに迷惑
無能残業者排除を政府が対策

残業代ゼロ法案
http://lite.blogos.com/article/109636/
1

266 :仕様書無しさん:2016/07/11(月) 20:47:44.42
プログラム読んで思い描くイメージも千差万別なんだぞ。
おまいが思い描くポインタと俺が描くポインタのイメージは違うからな。

267 :仕様書無しさん:2016/07/11(月) 20:57:58.21
そこで共感覚(シナスタジア)が一定に共有されやすい物が集団生活では好まれるのです。

268 :仕様書無しさん:2016/07/11(月) 20:59:17.14
共通解釈はあり得るよ。
じゃなきゃ、国語と言う教科は有り得ないからね。

まぁ、時々、おまいらのような千差万別理論で、国語を否定する輩もいるけどな。

269 :仕様書無しさん:2016/07/11(月) 21:11:51.77
何読んでもエロしか思う浮かばんのだが

270 :仕様書無しさん:2016/07/11(月) 21:17:39.22
そこで肛門快楽(アヌスアクメ)が一定の集団では好まれるのです。

271 :仕様書無しさん:2016/07/11(月) 21:23:32.85
>>262
> プログラム構造のイメージを作りながらコードを読む事
え、そんなん、レベルの違いはあっても、誰でもできるんじゃないの?

プログラミングが全然できない人に出会った事がないから、
よう分からんのです

272 :仕様書無しさん:2016/07/11(月) 21:23:51.10
やたらとアナルが好きな奴がいるな

俺もだけど

273 :仕様書無しさん:2016/07/11(月) 21:29:35.08
プログラミング言語で仕事選んでる奴はセンスない

274 :仕様書無しさん:2016/07/11(月) 21:35:05.60
コボラーかな?
俺はアナルで仕事を選ぶけど

275 :仕様書無しさん:2016/07/11(月) 21:39:42.65
>>273
特定の言語を指定してくる仕事は断ってるぜ
センスを活かすには熟知したMy道具は付き物だからな
職人に自分の道具を使うなとかふざけたことは常識的に言わないもんだけどな

276 :仕様書無しさん:2016/07/11(月) 21:45:32.78
スマホとPCで主要言語違うけど、勿体無い。

277 :仕様書無しさん:2016/07/11(月) 21:46:33.16
何が勿体ないの?

278 :仕様書無しさん:2016/07/11(月) 21:48:42.90
いつの間にかアナルスレになっててワロタ

279 :仕様書無しさん:2016/07/11(月) 22:49:54.73
いまどき言語の違いなんてそんなに変わらないでしょう

280 :仕様書無しさん:2016/07/11(月) 22:57:56.86
>>275みたいな釣りがぜんぜん面白くない

281 :仕様書無しさん:2016/07/11(月) 23:20:04.01
>>279
VCとperlで同じ成果物がつくれるのか?

282 :仕様書無しさん:2016/07/11(月) 23:21:30.44
>>280
釣りじゃねえよ
何でも引き受けるとかバカのする事だろ

283 :仕様書無しさん:2016/07/11(月) 23:24:31.48
アナルは十人十色

284 :仕様書無しさん:2016/07/11(月) 23:27:23.51
違うのは色だけじゃねえけどな

285 :仕様書無しさん:2016/07/11(月) 23:45:22.76
アナル好きはプログラミングのセンスがある

286 :仕様書無しさん:2016/07/12(火) 00:50:39.20
プログラマはアナル好き
一理あるわ

287 :仕様書無しさん:2016/07/12(火) 02:58:55.99
アナリストですね

288 :仕様書無しさん:2016/07/12(火) 03:00:49.13
センスのある男には女がいない。

これ真理。

289 :仕様書無しさん:2016/07/12(火) 04:03:16.34
8日ぶりに風呂に入った。

290 :仕様書無しさん:2016/07/12(火) 05:30:20.84
>>281
それは片方スクリプトだしね

291 :仕様書無しさん:2016/07/12(火) 08:53:16.00
SEの不健康と低知能の時間外労働違反対策

貧困と訴訟が増えて迷惑だから残業は辞めろ!
優秀なSEや共働きに迷惑だから残業は辞めろ!

時間外労働違反となる
将来削減の業界である
多数が嫌う職種である
共働き結婚妨害である
契約に作業期限はない
契約終了が早期化する
定年退職が早期化する
健康障害をもたらす
対人障害をもたらす
生産評価が低下する
生産能力が低下する
能力評価が低下する
時間報酬が低下する
情報技術が低下する
生涯収入が低下する
学習時間が減少する
副業時間が減少する
訴訟が増加する
失業が増加する
貧困が増加する
独身が増加する
早死が増加する5

292 :仕様書無しさん:2016/07/12(火) 10:07:13.19
この執念深さは気違いならではなんだろうね

293 :仕様書無しさん:2016/07/13(水) 21:39:00.73
>>290
だからなに?

294 :仕様書無しさん:2016/07/13(水) 22:55:55.58
外部仕様ならいけるんじゃね

295 :仕様書無しさん:2016/07/14(木) 09:09:28.93
>>290
vcでWindows版perlのコンパイル出来なかったっけ?

296 :仕様書無しさん:2016/07/14(木) 18:02:12.85
SEの報酬対効果と知的財産搾取の対策

相場下がって迷惑だから不利益開発するな!

報酬80万/月以下で設計するのは辞めろ!
報酬80万/月以下で実装するのは辞めろ!
10

297 :仕様書無しさん:2016/07/14(木) 18:57:58.36
Perl/Tk 使えばいいじゃない

298 :仕様書無しさん:2016/07/17(日) 10:36:07.89
SEの知的財産と契約料金の搾取対策

早死に貧困の助長だから偽装請負の従犯は辞めろ!
相場下がって迷惑だから報酬増やすか作業減らせ!

・IT社長に贅沢資金を搾取させるな
・平均年齢40歳未満の会社は辞めろ
・1,000万円/年以下の会社は辞めろ
・100万円/月以下の契約は辞めろ
・5,000円/時間以下の契約は辞めろ
・6時間/日以上のPC使用は辞めろ
・100万円/月以下のプログラムは作るな
・偽装請負の開発は辞めろ
・多重派遣の開発は辞めろ
・多重契約は止めろ
・残業見積りは止めろ
・不要作業は止めろ
・時間外労働違反は止めろ
・契約外作業期日は守るな
・客先指示に従うな
・不利益な依頼は断れ
・知的財産を渡するな
・生産効率を上げろ
・残業しないで学習しろ
・残業しないで副業しろ
・損害は訴えろ

【非婚】SI受注SEは3億円以下の低生涯収入【離婚】
http://hanabi.2ch.net/test/read.cgi/infosys/1451213054/
6

299 :仕様書無しさん:2016/07/17(日) 12:27:41.99
それよりも批判ばかりして
同僚と知識交換しない奴はいらん

300 :仕様書無しさん:2016/07/17(日) 13:41:18.84
知識交換って何?
教えてクレーってこと?

301 :仕様書無しさん:2016/07/17(日) 13:57:58.53
女子社員と体液交換ならしてもいい

302 :仕様書無しさん:2016/07/17(日) 16:52:36.23
たぶんダメダメばっか言ってどこがどうダメでどうしたらいいかって言うのをいいたいんじゃないかな

303 :仕様書無しさん:2016/07/17(日) 20:19:17.53
問題提起の難しさとか重要性わかってるか?

ダメダメ言うだけなのは、まだ期待されてるんだ
おまいらに解決策まで教えたら頭使わないだろ

304 :仕様書無しさん:2016/07/17(日) 20:29:44.34
教えたがりのくせにw

305 :仕様書無しさん:2016/07/17(日) 20:48:53.20
そうだよ
そこをあえて指摘までで抑えてるんだ
わかってんなら文句言わず頑張れ

306 :仕様書無しさん:2016/07/17(日) 21:14:48.61
教えたがりの独断に満ちた指摘()はいらんわ

307 :仕様書無しさん:2016/07/17(日) 21:26:07.07
独断が満ちてるってどういう状態か知らんが

指摘が間違ってると判断できるなら従わなくて構わんよ

308 :仕様書無しさん:2016/07/17(日) 21:29:40.65
なんで従うやねんwそれがお前の独断やw
指摘はacceptかrejectするのが先やでw

309 :仕様書無しさん:2016/07/17(日) 21:35:52.04
んじゃそのacceptやrejectする担当に文句言え

問題点がどこにあるか分からんバカ

310 :仕様書無しさん:2016/07/17(日) 21:38:29.59
>>309
この流れでは問題点はお前以外にないのだがw

311 :仕様書無しさん:2016/07/17(日) 21:47:21.66
そうね
バカにエサあげた俺が悪いね

312 :仕様書無しさん:2016/07/17(日) 21:49:44.68
そして独断により他人をバカ認定する事で心の平穏を保つ>311であった
めでたしめでたしw

313 :仕様書無しさん:2016/07/18(月) 00:37:45.61
こんなんばっか

314 :仕様書無しさん:2016/07/18(月) 03:23:05.84
マジレスしたら無関係な話をおっ始められた…

315 :仕様書無しさん:2016/07/18(月) 09:26:07.99
>>303
でたでた

316 :仕様書無しさん:2016/07/18(月) 09:27:13.18
日本のプログラマ業界の病気だわ

317 :仕様書無しさん:2016/07/18(月) 10:40:59.73
プログラマに限らず大体こんなもんやと思うで
周りは皆バカでなぜか自分だけ賢いねんw

318 :仕様書無しさん:2016/07/18(月) 10:51:46.59
SEの知的財産と契約料金の搾取対策

早死に貧困の助長だから偽装請負の従犯は辞めろ!
相場下がって迷惑だから報酬増やすか作業減らせ!

・IT社長に贅沢資金を搾取させるな
・平均年齢40歳未満の会社は辞めろ
・1,000万円/年以下の会社は辞めろ
・100万円/月以下の契約は辞めろ
・5,000円/時間以下の契約は辞めろ
・6時間/日以上のPC使用は辞めろ
・100万円/月以下のプログラムは作るな
・偽装請負の開発は辞めろ
・多重派遣の開発は辞めろ
・多重契約は止めろ
・残業見積りは止めろ
・不要作業は止めろ
・時間外労働違反は止めろ
・契約外作業期日は守るな
・客先指示に従うな
・不利益な依頼は断れ
・知的財産を渡するな
・生産効率を上げろ
・残業しないで学習しろ
・残業しないで副業しろ
・損害は訴えろ

【非婚】SI受注SEは3億円以下の低生涯収入【離婚】
http://hanabi.2ch.net/test/read.cgi/infosys/1451213054/
1

319 :仕様書無しさん:2016/07/19(火) 08:03:30.68
無能実態派遣残業して時間報酬相場下げるな!
【知的財産と契約料金の搾取促進者ばかり】
[SI生涯損害助長SEを追放すべき]
偽装請負従犯SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの迷惑
無償プログラム提供
事前面接
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
時間外労働違反
低予備工数見積
残業見積
無料追加
学習不足
裁判苦手
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
低収入低技術
非婚離婚
鬱病早死11

320 :仕様書無しさん:2016/07/20(水) 08:27:22.38
年収1,000万円以下の低レベルSEへ

SEの低生涯収入と短勤続年数の損害対策考えろ!
相場下がって迷惑だから交渉するか作業減らせ!
生産下がって迷惑だから技術は報酬で評価しろ!

[推定平均生涯収入]
100万/月 3億5,000万円以上(大卒サラリーマン上位レベル)
90万/月 3億円以上(大卒サラリーマン平均レベル)
80万/月 2億5,000万円以上(大卒サラリーマン下位レベル・高卒サラリーマン上位レベル)
70万/月 2億円以上(高卒サラリーマン平均レベル)
60万/月 1億5,000万円以上(高卒サラリーマン下位レベル)
50万/月 1億円以上(フリーターレベル)
40万/月 5,000万円以上(パートレベル)9

321 :仕様書無しさん:2016/08/24(水) 02:40:02.85
こう書いてるからこうすればうまくいくはずだ!
みたいな思考ができないんだよ・・・orz

コメントなんて全く信じないし、コードは全て把握しないと修正できない
特に割り込みやマルチタスクのようないつどこで何が起きるかわからない
プログラムの修正は苦手(仕様書がきっちりしてたら話は別だが・・・)

適当にパパっと修正する技術ってどうすれば身につくの?

322 :仕様書無しさん:2016/08/24(水) 04:04:41.82
>>321
どんな仕事でもそうだが仕事が速くて正確な人は10人に1人くらいで
あとは遅くて正確か、速くて適当かのどちらか。

「出来ました」と言うから「仕事速っ、すげー」と思ってチェックしたら全然できていなくて、
「出来なかったのか、しなかったのか」と突っ込みたくなるけど、もう二度と頼まないから
どうでもいいやと思ってバイバイする人もいる。

「コツコツ考えることをバカにしてはいけません、論理パズルが得意な人も
コツコツ考えているのです、それも高速に。」

論理パズルの本の前書きに書いてあったけどやっぱりコードをひたすら読んで
地道に考えてるうちにだんだん速くてなっていくのだと思う。

323 :仕様書無しさん:2016/08/24(水) 08:29:01.43
>>321
完全に把握すれば良いと思うよ。
完全に把握してないけど早い、なら誰にでも出来るんだから。

だから、関数ごとにin/outははっきりさせよう、リエントラントに作ろう、依存する状態は入力に貰おう、ってコーディングに繋がるよ。
そういうコードであれば、完全に把握するのはこの範囲で良いんだな、って明確だから。

324 :仕様書無しさん:2016/08/26(金) 00:09:09.81
>>321
クソコード書いた奴を思い切り殴れ

325 :仕様書無しさん:2016/08/27(土) 06:51:08.80
>>321
ボトムアップによる理解とトップダウンによる把握を同時にやれるようにする。
ボトムアップは論理の蓄積。コツコツ考えるしかないが、訓練して速度と正確性を上げる。
トップダウンはパターンの蓄積。沢山のコードを読み込んだり失敗した経験を元に可能性の絞り込みを速くする。
あなたはトップダウンのアプローチが苦手なようだから、そこを意識するといいかも。
そうしたら、間違ったコメントや汚いコードからでも役に立つ情報を読み取って手掛かりに出来るようになるはず。

326 :仕様書無しさん:2016/08/29(月) 08:24:58.42
機能に関わるコードを局所化できてない
カスみたいなプログラムはほんとバグの温床

327 :仕様書無しさん:2016/08/29(月) 20:28:02.41
関数を中までたどらずに
とりあえず一つの関数を上から下まで読んで、
呼び出してる関数の仕事は推測で済ませるという技を学んで
だいぶ把握がはやくなった。

それが上手くできないときは俺じゃなくてプログラムの作りが悪い。
ということに決めた。

328 :仕様書無しさん:2016/08/29(月) 21:35:19.93
俺が思う本当のセンスは、

1: 文字(記述)と動作の脳内関連付けによる思考内動作が出来るか
→ できなければそもそもプログラムは無理

2: 平面的で小さな規模だが、複雑な処理構造やループを記述の手を止めることなく書くことが出来るか
→ 同一だが動的な変化を伴っている物が脳内処理できない。
プログラミングは不可能ではないがほぼ無理


3: 再帰では動作の(数学的な)3次元構造が発生する。簡単な処理で良いので、それを脳内で再現出来るか。
→ これができないとプログラミングが著しく遅く、また基本的な数学や処理にも苦労するケースがある


4:外部仕様を満たすに当たって、常に同じ方式で一貫性を持って書けるか。
また周囲(他人)の書きかたに同調性した記述や処理構造が一貫して書けるか
→ できなければあなたはゴミ製造機

5:他人が書いた記述を、(書式や構造がある程度一貫していれば) 可能な限り細部まで把握して理解してから手を入れれるか
→ できたのなら、おそらくバグに近いレベルの何かを1つや2つ発見できるはず。常に出来るならプロでも平均点以上。

329 :仕様書無しさん:2016/08/29(月) 21:56:09.20
短く簡潔に纏められるのがプログラムセンスだと思う

330 :仕様書無しさん:2016/08/29(月) 22:04:54.68
>>328
日本語の時点ですでにスパゲッティじゃねーか

331 :仕様書無しさん:2016/08/29(月) 23:52:31.85
センスがある人っていつも僕が考えた最強のセンスみたいなの考えてるの?

332 :仕様書無しさん:2016/08/30(火) 09:31:33.69
【犯罪者追放のお願い】

違法派遣(偽装請負・多重派遣・偽装出向・事前面接等)についての刑事罰
【告訴権者=業務委託、準委任、共同受注、業務請負契約および特定派遣(契約・正規)、一般派遣、正規社員】

@職業安定法第44条の労働者供給事業の禁止規定に違反(1年以下の懲役または20万円以下の罰金)
 ■偽装請負・多重派遣・偽装出向・多重出向
 ■事前面接(顔合わせ・面談・職場見学等)と履歴書・職務経歴書・スキルシート等提出による労働者の特定(※)
(音声録音で立証可能)
A労働基準法第6条(中間搾取の禁止) (1年以下の懲役又は50万円以下の罰金)
 ■多重派遣・多重出向

※違法派遣(派遣労働者の特定)→派遣法で認められた派遣労働者ではない→労働者供給事業→職業安定法44条違反というの
が前提となる法解釈となります。派遣法における罰則が軽微なのは法律の不備や労働者軽視などが原因ではありません。
違法派遣は全て職業安定法44条で裁くことが可能なため、刑罰の重複を避けるために派遣法には軽微な罰則(主に裁量行政による)しかないのです。

使用者に有利な民事訴訟や労働関係諸局への通報等の対極にあるのが書面(告訴状)による刑事告訴(※告訴先は検察の直告班)です。
労働関係諸局への通報・斡旋による軽微な「適正化」や監督・指導に対して、法律に定められた刑事罰を問うことになり、
違法派遣業者にとって有罪は考えられる限り最大の処罰となります。同時に刑事罰を受けた
担当者が取引先に与える悪印象を考慮すれば、通常会社側は告訴が受理された時点で告訴取り下げに
動くのが妥当でしょう。懲役、前科がつく刑罰が下される可能性から、告訴取り下げの和解金は高額となることが多いのです。

告訴の流れとしては、
刑事告訴⇒告訴受理⇒告訴取下げ要請⇒取下げ和解金入金⇒告訴取下げ
となります。告訴の懲役刑適応は犯罪者個人に対してのみですので、告訴する対象は
派遣先・派遣元 社員
派遣先・派遣元 社長
派遣先・派遣元 担当者・責任者・管理役員・取締役
派遣先・派遣元 人事管理担当者・人事管理役員・取締役
が妥当です。
刑事告訴取り下げの和解金額は犯罪者個人と交渉するとよいでしょう。(告訴状は人数分提出する必要あり)

333 :仕様書無しさん:2016/08/31(水) 10:04:50.46
【犯罪者追放のお願い】

犯罪者個人に対して告訴状を偽装請負・偽装出向・多重派遣の被害者が作成(刑事告訴は無料) or 司法書士が代筆(料金は5万円ぐらい)

告訴状を【検察の直告班】に郵便局の内容証明付で送付(疎明資料・証拠にはICレコーダー、スマホによる録音が適しています)

審査 → 不受理 → 告訴状再提出または刑法 第193条で訴えを起こす

受理 → 告訴事実を認め示談交渉(↓) →示談成立  →法廷相場50〜100万円の示談金 ※示談拒否が良い
↓                ↓
事案化 ←←←←←← 示談不成立(↓) →示談外交渉 →犯罪者の年収半額×最大懲役年数の和解金支払い※推奨
↓                ↓
↓               起訴  →公判  →罰金刑=前科(起訴事実を認めてるため)→追討ち民事訴訟
↓                    
審査 → 起訴(強制捜査・留置場)→ 公判 → 懲役刑などの厳罰(反省が認められないため)→追討ち民事訴訟

不起訴、起訴猶予

検察審査会法第30条(検察審査会へ申し立て)→ 起訴 → 起訴後は同上
刑法 第193条(公務員職権濫用)で検察事務官を刑事告訴 → 同上

◎告訴→告訴受理→示談交渉→厳罰を求め示談不成立→示談外交渉→和解金支払い・和解契約(公正証書・即決和解で秘密保持契約)
◎偽装請負・出向・違法派遣事件では派遣・出向先両方の代表者、役員、現場責任者に告訴できます。
前科がついた犯罪者が法人の代表であれば公的な入札からの排除、取引先や顧客との契約解除など社会的制裁・批判に晒されることから辞職または解任が妥当、役員・社員であれば懲戒を想定。
◎事業者内部の加害関係者による刑事告発(刑事訴訟法239条1項)も可能です。
加害者本人、管理間接部門の社員が刑事告発に踏み切る場合も和解金による解決が妥当です。

注意:告訴が受理されない理由
●3年間(※)の時効が過ぎたもの ※違法派遣
●同一事実について過去に告訴取消しがあったもの
●関連する民事訴訟を有利に導く目的の場合
●証拠が希薄なもの ※被害者が契約時に違法派遣・偽装請負・多重派遣と知っていても刑事告訴は有効です。

334 :仕様書無しさん:2016/09/01(木) 10:05:57.93
【犯罪者追放のお願い】

告訴の趣旨
 被告訴人は、以下に該当すると考えるので、被告訴人の厳重な処罰を求めるため告訴します。
●職務経歴書を提示した事前面接を実施・偽装請・偽装出向
 労働者派遣法第26条(契約の内容等)に違反
職業安定法第44条(労働者供給)に違反
●多重派遣・多重出向
 労働基準法第6条(中間搾取の禁止)に違反

疎明資料
■事前面接日時・場所・出席者・資料のコピー、音声記録
 就業場所・就業期間・就業時間
 指揮命令
  指示を誰が行っているかの記録、音声記録
 仕事で使う道具や、資材の負担(所有)のあり方
  業務で使用しているパソコン・備品などの所有者
■契約書
 請負・雇用契約書、出向指示など書面のコピー

刑事告訴ガイダンス
★和解金の相場は犯罪者の去年の年収の半額です。社長や役員で数千万〜1億円、管理職で500〜1000万円、営業個人については200〜500万円程度。
★痴漢も民事でなく刑事事案ですが、裁判所が和解金を被害者に支払わせて解決するのが絶対的過半数です。和解で解決しない事案、つまり公訴までいって判例となる事例を探すほうが難しいことでしょう。
★録音は一方の当事者が取る限り合法です。※加害者に録音の同意を求める必要はありません。
★告訴状を検察に提出しても受理されなければ加害者側には知られることはありません。不受理の場合は何事も起きてないように粛々と振る舞ってください。
★告訴を取り下げるとき検察に提出した資料は全て返却されます。また検察があなたが提出した証拠をあなたの許可なく裁判の証拠として使用はできません。告訴を取り下げたのちの録音資料には当事者の立場が失われるため証拠能力はありません。
★和解時に告訴した事実は秘匿事項となります。犯罪者が秘密保持契約に違反した場合の損害賠償金は「即決和解」か「公正証書」で最低5000万円〜にしましょう。支払いを拒否すれば強制執行手続きを地方裁判所に上訴(裁判不要)してください。
★派遣会社や事業会社が同業者に情報をリークしたなら競合他社に弱みを握られます。余程信用のおける相手でなければリークはできないでしょう。漏らした方の口が軽ければ事実は分かります。また密告してくれた事業者には損害賠償金の3割を謝礼金として渡してください。

335 :仕様書無しさん:2016/09/02(金) 08:14:33.96
【犯罪者追放のお願い】
大金・知財・健康・家族を失ってからでは、取り返しがつきません。
犯罪者に従うのも犯罪です。犯罪行為を最寄りの警察署に通報して下さい。
※通報者のプライバシーは保護されます。

刑法62条 幇助罪
犯罪行為を幇助した

刑法第246条 詐欺罪
虚偽による契約を交付された

刑法第223条 強要罪
作業の期日等を強要された

刑法第234条 威力業務妨害罪
職権等の威力によって業務を妨害された

職業安定法第44条 労働者供給事業の禁止
業務の時間、場所、方法等を指揮命令された

警察官の対応に問題があった場合は、 監察局、
各都道府県の警察本部監察官室、 公安委員会に苦情申出して下さい。

http://www.gov-online.go.jp/useful/article/201111/3.html

336 :仕様書無しさん:2016/09/09(金) 09:50:19.45
無能実態派遣残業して時間報酬相場下げるな!
【知的財産と契約料金の搾取促進者ばかり】
[SI生涯損害助長SEを追放すべき]
偽装請負従犯SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの迷惑
無償プログラム提供
事前面接
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
時間外労働違反
低予備工数見積
残業見積
無料追加
学習不足
裁判苦手
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
低収入低技術
非婚離婚
鬱病早死

337 :仕様書無しさん:2016/09/10(土) 18:28:40.06
SI受注SEの知的財産と契約料金の搾取対策

早死に貧困の助長だから偽装請負の従犯は辞めろ!
相場下がって迷惑だから報酬増やすか作業減らせ!

・IT社長に贅沢資金を搾取させるな
・客先経営資金削減の犠牲になるな
・平均年齢40歳未満の会社は辞めろ
・6時間/日以上PC使用の会社は辞めろ
・1,000万円/年以下の会社は辞めろ
・100万円/月以下の契約は辞めろ
・5,000円/時以下の契約は辞めろ
・100万円/月以下のプログラムは作るな
・偽装請負の開発は辞めろ
・多重派遣の開発は辞めろ
・多重契約は辞めろ
・残業見積りは止めろ
・不要作業は止めろ
・時間外労働違反は止めろ
・契約外作業期日は守るな
・客先指示に従うな
・不利益な依頼は断れ
・知的財産を渡するな
・生産効率を上げろ
・残業しないで学習しろ
・残業しないで副業しろ
・損害は訴えろ

【非婚】SI受注SEは3億円以下の低生涯収入【離婚】
http://hanabi.2ch.net/test/read.cgi/infosys/1451213054/

338 :仕様書無しさん:2016/09/11(日) 09:29:07.16
技術屋の家族かわいそう

技術ない方が収入と寿命高いって有り得ないだろ!
相場下がって迷惑だから収入上げるか技術下げろ!

放送・商社・銀行・公務 > 製造・化学・通信・情報

2014年度有価証券報告書より
伊藤忠商事 1,395万円(41.5歳)
三菱商事  1,376万円(42.6歳)
三井物産  1,361万円(42.4歳)
丸紅    1,306万円(41.5歳)
住友商事  1,301万円(42.8歳)

http://m.finance.yahoo.co.jp/stock/fundamental?code=4676.T

339 :仕様書無しさん:2016/09/15(木) 22:10:11.92
1クラスが5000行超えて何の疑問も感じない奴は向いてないと思う

340 :仕様書無しさん:2016/09/15(木) 22:51:40.46
向いてないっつうか、死んでください
採用した会社の人事もろとも

341 :仕様書無しさん:2016/09/15(木) 22:53:32.05
それと、1メソッド1kオーバーも死刑

342 :仕様書無しさん:2016/09/16(金) 01:52:07.58
そんな書けない。
凄い

343 :仕様書無しさん:2016/09/16(金) 02:07:54.24
いや凄くねーから

344 :仕様書無しさん:2016/09/16(金) 10:03:07.96
年収1,000万円以下の低レベルSEへ

SEの低生涯収入と短勤続年数の貧困対策考えろ!
報酬下がって迷惑だから交渉するか作業減らせ!
生産下がって迷惑だから技術は報酬で評価しろ!

[推定平均生涯収入]
100万/月 3億5,000万円以上(大卒サラリーマン上位レベル)
90万/月 3億円以上(大卒サラリーマン平均レベル)
80万/月 2億5,000万円以上(大卒サラリーマン下位レベル・高卒サラリーマン上位レベル)
70万/月 2億円以上(高卒サラリーマン平均レベル)
60万/月 1億5,000万円以上(高卒サラリーマン下位レベル)
50万/月 1億円以上(フリーターレベル)
40万/月 5,000万円以上(パートレベル)

345 :仕様書無しさん:2016/09/16(金) 10:36:56.52
パートって40万なの?

346 :仕様書無しさん:2016/09/16(金) 18:22:22.77
>>345
IT取引ではね

347 :仕様書無しさん:2016/09/16(金) 22:08:41.77
1k=400字詰め原稿用紙一枚

348 :仕様書無しさん:2016/09/17(土) 11:41:12.90
SI受注SEの知的財産と契約料金の搾取対策

早死に貧困の助長だから偽装請負の従犯は辞めろ!
相場下がって迷惑だから報酬増やすか作業減らせ!

・IT社長に贅沢資金を搾取させるな
・客先経営資金削減の犠牲になるな
・平均年齢40歳未満の会社は辞めろ
・6時間/日以上PC使用の会社は辞めろ
・1,000万円/年以下の会社は辞めろ
・100万円/月以下の契約は辞めろ
・5,000円/時以下の契約は辞めろ
・100万円/月以下のプログラムは作るな
・偽装請負の開発は辞めろ
・多重派遣の開発は辞めろ
・多重契約は辞めろ
・残業見積りは止めろ
・不要作業は止めろ
・時間外労働違反は止めろ
・契約外作業期日は守るな
・客先指示に従うな
・不利益な依頼は断れ
・知的財産を渡するな
・生産効率を上げろ
・残業しないで学習しろ
・残業しないで副業しろ
・損害は訴えろ

【非婚】受注SEは3億円以下の低生涯収入【離婚】
http://hanabi.2ch.net/test/read.cgi/infosys/1473857318/

349 :仕様書無しさん:2016/09/18(日) 01:32:38.73
>>331
どっちかというとこのスレみたいに絶望的にセンスがない奴がいる
求めてるのはそんな大したことじゃない

350 :仕様書無しさん:2016/09/18(日) 01:38:41.09
最近は語彙の豊富さ=プログラムセンス
と思うようになってきた

適切に名前付ける力があったらたいていのことは困らない

351 :仕様書無しさん:2016/09/18(日) 09:39:50.36
あんまりそう思わない

適切に名前を付けられるように、コードを整理・構築できるスキルだと思うけど

名前が付けられない人、変な名前を付ける人って、
例えば1つのメソッドやクラスにてんこ盛りする傾向が高い

もし名前で悩んだら、「奥さん、そのコード臭いませんか?」と自問した方がいい
名前を必死に考えるのではなくて

352 :仕様書無しさん:2016/09/18(日) 12:09:11.94
いやほら、関数名はそうだけど、プロパティ名とか
名詞は英語力いるじゃん

353 :仕様書無しさん:2016/09/18(日) 12:32:26.69
最近は日本の商習慣だとか自社文化()みたいなものを表現する列挙型や定数には日本語使ってる、ローマ字じゃない方の。
言語によってはサポートしてないけど、試しにやってみるとチームメンバーの人種や開発体制、オフショアに投げるか等によってはしっくりくるかもしれないよ。

354 :仕様書無しさん:2016/09/18(日) 12:56:23.41
>>352
同意だけど、
語彙の豊富さって言うより、英語力かな

昔と違って簡単に翻訳が可能になったが、
翻訳結果を精査せず鵜呑みしてるとアホな名前になる

日本語の設計書やコメントが無いとソース解読が困難
って言う人は、大概、命名も変である

355 :仕様書無しさん:2016/09/18(日) 13:05:34.68
>>353
お互い、日本語としては理解してるが
該当する英語(そもそもの概念すら)が存在しないってパターンだな
確かに日本語のままの方が伝わりやすい

356 :仕様書無しさん:2016/09/18(日) 15:20:57.07
プログラムで使う英語なんか
決まってるんだし
どうでもいい

357 :仕様書無しさん:2016/09/18(日) 15:39:16.15
他社回線契約開始日時
OtherCompanyLineContractBeginDate

なんかもにょる

358 :仕様書無しさん:2016/09/18(日) 16:53:14.87
こういう長ったらしいやつは、正規化できて無いことが多いよな
他社回線契約の属性として契約開始日とかになるはず

つか契約開始日時ってなんだ?
契約日と利用開始日が混ざってるのか?
普通は契約日と契約期間だよな
時間までは要らねー気がするし

359 :仕様書無しさん:2016/09/18(日) 18:51:15.87
>>357
other_company.line_contract.begin_date

360 :仕様書無しさん:2016/09/18(日) 19:56:29.65
>>358
何かの開始終了に時間はあった方が便利だよ。
日本時間なのか海外時間なのか、国情報とタイムゾーン持つより、GMTで持っといたほうがなんやかんや便利。
期間も同じ理由で、何かが始まって終わる期間に単位時間×日数と持つと、その人の本当に経由する日数と終了する日が乖離するし、何かが終わって何かが始まる類の比較が面倒なので、終了日時で持った方が楽。

361 :仕様書無しさん:2016/09/18(日) 20:10:17.10
契約日と契約期間を別にすると
多分クエリで引っ掛けるときにインデックスが使われるかどうかで問題になる

362 :仕様書無しさん:2016/09/18(日) 20:53:10.29
>>360
それは分かるけど、回線契約の運用で必要となるシーンは無いはず
しかも仕様として時間を生かすなら「便利かも」ではダメで、設計段階から確固とした意味をもたせる必要がある
なので考える事を増やしたくない俺は時間を除外する

>>361
性能絡みは問題が出てから考える
設計がある程度正しければ、そんなに問題にはならないし、十分な性能も出る
つか項目分けてもインデックス貼れるでしょ?

363 :仕様書無しさん:2016/09/18(日) 21:14:14.07
>>362
契約日と契約期間が分かれてるってことは
契約日に契約期間足して検索するんだろ?
関数インデックスが使えるDBならいいけどな。
使えなかったらやばいことになる。

364 :仕様書無しさん:2016/09/18(日) 21:15:52.77
ただ論理的に結合していればいいてのは
保守したことが無い人の考えだね

365 :仕様書無しさん:2016/09/18(日) 21:47:37.95
>>363
なんでクエリー上で足すかな?

366 :仕様書無しさん:2016/09/18(日) 21:50:03.36
>>364
SQL書けない人ですかね
覗いてるスレが不適切ですよ

367 :仕様書無しさん:2016/09/18(日) 22:02:30.75
テーブル作った人は保守がめんどいから正規化しなかったって言ってたな
でもそれでうちのチーム他よりうまくいってたし

書類だっていちいち正規化なんてしないし
それで世の中回ってるんだから
リソースがふんだんにあるなら、正規化なんていらんのかもしらん

368 :365:2016/09/18(日) 22:02:40.23
すまん、脳内設計だけで説明が抜けた

回線契約とかの終了日は基本的に月単位の締日でやるから、そんな厳密な日付計算要らなくて
開始日と契約の種類(2年縛りとか)で検索できるはず

369 :仕様書無しさん:2016/09/18(日) 22:05:31.48
>>367
開発規模による

370 :仕様書無しさん:2016/09/18(日) 22:36:10.25
>>362
回線契約なら尚更要るんじゃない?
契約に対してあるキャリアは0時起点、あるキャリアは朝何時起点が噛むと最悪だと思う。
月も同じで、ソフバンなんかだと締め日が3つに別れてて計算上の締め日と請求時の対象期間と契約月がそれぞれめんどくさいはず。
他社に海外キャリアやら、契約期間に対するローミング期間が死ぬほど面倒くさくなるよ。

371 :仕様書無しさん:2016/09/18(日) 22:39:37.43
プラン自体は契約した瞬間or翌日or月初とか適用開始日も違うしな。

372 :仕様書無しさん:2016/09/18(日) 23:21:16.10
>>370
いや必要ならば終了日があっても構わんよ
元々の話に戻すと、契約日と利用開始日(期間)は違う項目だってこと

項目を持たせる以上はハッキリと意味を持たせる
理論的に分けるべき項目をくっつけない

言いたいのは、これだけ

つか、他社の回線契約をそこまで面倒見る必要あるの?
俺的な純粋な疑問

373 :仕様書無しさん:2016/09/18(日) 23:39:01.37
>>372
元の項目、契約開始日時しか無くない?
契約日ってのが何を指してるかわからんけど、少なくとも利用開始日時とイコールとは読めないけど。

契約上、開始日時があるんじゃないの?
何時何分に契約したら、何時何分以降ないし、翌日何時以降から契約上有効な期間が開始するって意味意外にないと思うけど。

論理的に分けるべき項目が定義されてないのに、それが必要だと言われてもわからん。

他社の契約期間が大切なものはあるよ。
MNPなんかは、元のキャリアの交換器が移転先キャリアに振ってるし。

374 :仕様書無しさん:2016/09/19(月) 00:29:22.53
>>373
そういう端的な話じゃなくてさ
それこそ大元は長ったらしい名前は要注意ってことで
もしかしたら別項目なんじゃないか、と疑いをかけただけだ
一応「?」って付けてるだろ(言い訳

MVPの話は参考になった
さんくす

375 :仕様書無しさん:2016/09/19(月) 00:30:22.28
なんだMVPって…
MNPだ

376 :仕様書無しさん:2016/09/19(月) 00:59:08.61
>>365
契約日に契約期間足さなかったら契約終了日が判らないだろ
契約終了している対象を省くにはどうクエリを書くんだ?

377 :仕様書無しさん:2016/09/19(月) 01:02:30.02
FromToのToを条件に含めたいのに
ToがFromにDate足さないと出てこないんだろ?

そんな設計あるかよ。。

378 :仕様書無しさん:2016/09/19(月) 01:23:46.19
>>376
普通は逆だよ。
開始日と終了日の間に超える締め時間の数を契約日数と数える。

379 :仕様書無しさん:2016/09/19(月) 01:34:45.92
>>378
うんそうだよね
>>358はおかしいよね

380 :仕様書無しさん:2016/09/19(月) 03:14:12.49
業務知識より技術力とか偉そうなこと言ってる奴が、こうやって商習慣も知らずにとんちんかんな設計するんだろうな

381 :仕様書無しさん:2016/09/19(月) 04:10:23.71
>>380
ああ、そのとおりだよ
業務知識より技術力だ
(システム化の要件として)無駄な商習慣は消していこうと常々考えている

そもそも実際の設計なら話の経緯も分かるし、ここまでアホな提言はしない
頓珍漢な設計をするのは、その商習慣、というか過去の悪習に疑問すら持たないヤツらだ

おまいらのレベルがよく分かったよ



じゃあの

382 :仕様書無しさん:2016/09/19(月) 04:40:25.25
自分が正しいと信じ込みたいがために、よく知らない商習慣を悪習と決めつけ、
よく知らない商習慣をなくせると思い込むスタイル
で、成果はなしw

383 :仕様書無しさん:2016/09/19(月) 09:10:09.62
>>380
技術力というより実務やってたら気付く事だと思うけどね。
机上でしか設計したことないのかな?

384 :仕様書無しさん:2016/09/19(月) 10:00:25.88
技術屋の家族かわいそう

技術ない方が収入と寿命高いって有り得ないだろ!
相場下がって迷惑だから収入上げるか技術下げろ!

放送・商社・銀行・公務 > 製造・化学・通信・情報

2014年度有価証券報告書より
伊藤忠商事 1,395万円(41.5歳)
三菱商事  1,376万円(42.6歳)
三井物産  1,361万円(42.4歳)
丸紅    1,306万円(41.5歳)
住友商事  1,301万円(42.8歳)

http://m.finance.yahoo.co.jp/stock/fundamental?code=4676.T

385 :仕様書無しさん:2016/09/19(月) 11:31:36.44
>>383
と言うより、実務≒商習慣含むその業務をシステムによって楽にするものの構築だからね。
それに対して、過去の業務を整理することは大切だけど、無駄は業務はあれど、商習慣は無駄ではあんまり無いし、
消したところで同業他社には同じ商習慣が残ってるんだから、ハブ的な所作って吸収するレイヤーが必要になってしまうんだよねえ。

過去の悪習なんか、割とカイゼンカイゼン言う会社は落ち着くところに落ち着いてるんだから、それ突付いたら大騒ぎになっちゃう。

386 :仕様書無しさん:2016/09/19(月) 12:00:48.29
むしろ悪習が多いのは、業務よりも開発現場の方か

387 :仕様書無しさん:2016/09/19(月) 12:12:45.10
>>385
その商習慣がコンピュータやインターネットを考慮しない時代に
作られたものだから、今の時代からすると効率が悪いんだよ。

388 :仕様書無しさん:2016/09/19(月) 13:45:05.37
>>387
えー?例えば?
カンバンなんて、そのまま電子化してソリューション売りしてたりするじゃん。
銀行の窓口は3時まで、とかかな。
あの後中では未だに大変な事してるけど、そりゃプログラムとかシステムでなんとかなるもんでもない。
なるなら、バイト雇って金で物理攻撃してるよ。
その典型がレンズ設計じゃん。

389 :仕様書無しさん:2016/09/20(火) 01:01:58.51
実力とのバランスで実装方法変えないといけないのに
どんな天才でもバカでも同じ方法でやらせようとするのってどうなの?
保守考えたら仕方ないの?

390 :仕様書無しさん:2016/09/20(火) 23:10:02.59
指示するだけの作れない人は、全員が同じ技量で同じ物が
まるでコピーしたかのように作れると信じてやまない阿呆だから

391 :仕様書無しさん:2016/09/21(水) 01:31:46.97
>>387
結局例は出せずか。口だけなんだなお前って。
今後は身の程を弁えた発言をするように。

392 :仕様書無しさん:2016/09/21(水) 01:34:23.23
>>391
なんか嫌なことでもあったか?w

393 :仕様書無しさん:2016/09/21(水) 01:43:47.10
すまん
許してやってくれ
全ては俺の責任だ

394 :仕様書無しさん:2016/09/21(水) 01:59:04.01
口だけ意識高い

395 :仕様書無しさん:2016/09/21(水) 09:41:00.40
【犯罪者追放のお願い】

違法派遣(偽装請負・多重派遣・偽装出向・事前面接等)についての刑事罰
【告訴権者=業務委託、準委任、共同受注、業務請負契約および特定派遣(契約・正規)、一般派遣、正規社員】

@職業安定法第44条の労働者供給事業の禁止規定に違反(1年以下の懲役または20万円以下の罰金)
 ■偽装請負・多重派遣・偽装出向・多重出向
 ■事前面接(顔合わせ・面談・職場見学等)と履歴書・職務経歴書・スキルシート等提出による労働者の特定(※)
(音声録音で立証可能)
A労働基準法第6条(中間搾取の禁止) (1年以下の懲役又は50万円以下の罰金)
 ■多重派遣・多重出向

※違法派遣(派遣労働者の特定)→派遣法で認められた派遣労働者ではない→労働者供給事業→職業安定法44条違反というの
が前提となる法解釈となります。派遣法における罰則が軽微なのは法律の不備や労働者軽視などが原因ではありません。
違法派遣は全て職業安定法44条で裁くことが可能なため、刑罰の重複を避けるために派遣法には軽微な罰則(主に裁量行政による)しかないのです。

使用者に有利な民事訴訟や労働関係諸局への通報等の対極にあるのが書面(告訴状)による刑事告訴(※告訴先は検察の直告班)です。
労働関係諸局への通報・斡旋による軽微な「適正化」や監督・指導に対して、法律に定められた刑事罰を問うことになり、
違法派遣業者にとって有罪は考えられる限り最大の処罰となります。同時に刑事罰を受けた
担当者が取引先に与える悪印象を考慮すれば、通常会社側は告訴が受理された時点で告訴取り下げに
動くのが妥当でしょう。懲役、前科がつく刑罰が下される可能性から、告訴取り下げの和解金は高額となることが多いのです。

告訴の流れとしては、
刑事告訴⇒告訴受理⇒告訴取下げ要請⇒取下げ和解金入金⇒告訴取下げ
となります。告訴の懲役刑適応は犯罪者個人に対してのみですので、告訴する対象は
派遣先・派遣元 社員
派遣先・派遣元 社長
派遣先・派遣元 担当者・責任者・管理役員・取締役
派遣先・派遣元 人事管理担当者・人事管理役員・取締役
が妥当です。
刑事告訴取り下げの和解金額は犯罪者個人と交渉するとよいでしょう。(告訴状は人数分提出する必要あり)

396 :仕様書無しさん:2016/09/22(木) 10:56:34.54
SI受注SEの知的財産と契約料金の搾取対策

早死に貧困の助長だから偽装請負の従犯は辞めろ!
相場下がって迷惑だから報酬増やすか作業減らせ!

・IT社長に贅沢資金を搾取させるな
・客先経営資金削減の犠牲になるな
・平均年齢40歳未満の会社は辞めろ
・6時間/日以上PC使用の会社は辞めろ
・1,000万円/年以下の会社は辞めろ
・100万円/月以下の契約は辞めろ
・5,000円/時以下の契約は辞めろ
・100万円/月以下のプログラムは作るな
・偽装請負の開発は辞めろ
・多重派遣の開発は辞めろ
・多重契約は辞めろ
・残業見積りは止めろ
・不要作業は止めろ
・時間外労働違反は止めろ
・契約外作業期日は守るな
・客先指示に従うな
・不利益な依頼は断れ
・知的財産を渡するな
・生産効率を上げろ
・残業しないで学習しろ
・残業しないで副業しろ
・損害は訴えろ

【非婚】受注SEは3億円以下の低生涯収入【離婚】
http://hanabi.2ch.net/test/read.cgi/infosys/1473857318/

397 :仕様書無しさん:2016/09/22(木) 12:00:46.40
変数名に助動詞入ってる奴昔見たな

398 :仕様書無しさん:2016/09/22(木) 12:05:57.28
>>397
普通でしょ

399 :仕様書無しさん:2016/09/22(木) 12:39:19.75
普通に見かけるのは確かだが
それが普通と思うならセンスがあるとは思えんな

400 :仕様書無しさん:2016/09/22(木) 12:52:55.37
変数は、静的な抽象概念、と言う位置づけだからね。一応ね。

料理皿を見て灰皿だと言い張る人や、冷蔵庫を開けっ放しにしてクーラーと言い張る人も稀にいるから困る。
変数も動的な抽象概念と屁理屈を言い張られると、それを論破するのは無理。
と言うか論破しようとすること自体が矛先違うしセンスないか。

401 :仕様書無しさん:2016/09/22(木) 13:14:01.70
オブジェクトの状態を保持するboolean型変数の名前が受身だったり完了だったりって、よく見かけるじゃん

402 :仕様書無しさん:2016/09/22(木) 13:34:37.23
まあそれ自体は動かないから普通は名詞つけるかなあ

403 :仕様書無しさん:2016/09/22(木) 14:19:01.31
>>402
名詞にこだわるのはセンスない

404 :仕様書無しさん:2016/09/22(木) 19:18:21.87
つか上流でクラス設計くらいやれよ無能

405 :仕様書無しさん:2016/09/22(木) 21:46:28.25
VBで誰がやっても似たような風になるソースって
実はけっこう練られてるんだなって最近気づいた
人数かければかけるほど仕事が進むように作るっていうのは難しい

406 :仕様書無しさん:2016/09/22(木) 23:10:39.12
> VBで誰がやっても似たような風になるソースって

どの言語であってもそうはならない。

407 :仕様書無しさん:2016/09/23(金) 00:19:02.60
>>404
上流でクラス設計ってアホかw

408 :仕様書無しさん:2016/09/23(金) 00:25:54.65
え?

409 :仕様書無しさん:2016/09/23(金) 00:39:45.50
>>407
アホはお前だろwプログラマの上流って詳細設計をする孫受けの事だぜw

410 :仕様書無しさん:2016/09/23(金) 21:54:18.49
>>397はごく普通じゃね?

例えば、rendered, persisted, purged, expanded などのboolean値

>>402みたいに、名詞にするって人は、わざわざ rendered_flgとかにするのかな・・・

言語によっては、敢えてcanやisを付けるのが慣習のもあるわね (Javaとか)

なんか変な事言ってるかな俺

411 :仕様書無しさん:2016/09/23(金) 21:59:14.62
注意深くデータ構造と初期処理を考えれば、例外など発生しない。

412 :仕様書無しさん:2016/09/23(金) 22:03:04.31
>>405
VB.NETの事だと思うけど、レガシーVBのことかい?

昔のレガシーVBは比較的誰がやっても同じになったね
標準ライブラリが豊富ではなかったし、
今みたいに、継承、クロージャー、非同期Promise、
デザパタやらそういうのまず無かったし

VB.NETで誰が書いても同じになるってことは、
レガシーVB+αの知識しかない人が集まって、
コード書いてるってことになりそうだ

413 :仕様書無しさん:2016/09/23(金) 22:06:07.69
非同期Promise(笑)

414 :仕様書無しさん:2016/09/23(金) 22:41:30.94
>>412
> 昔のレガシーVBは比較的誰がやっても同じになったね

クラスモジュールとインターフェースはどう使っていたかい?

415 :仕様書無しさん:2016/09/23(金) 23:40:49.20
>>411
例外という日本語の意味を調べろ

416 :仕様書無しさん:2016/09/23(金) 23:58:11.07
>>410
flgは止めてくり
何が真なのかわからん

417 :仕様書無しさん:2016/09/24(土) 00:05:43.17
>>411
君が何も入っていないコンピューターを与えられたら、
なんのソフトウェアを作って入れるのかは知らないが、
一度停電すれば2度と電源が入らなくなるし、
一度デバイスを見失えば入出力ができなくなって誰も手出しできなくなるだろう。

処理資源の上限管理についても同じだし、
CPUが一度に扱うビットの数についても同じだし、
HDDに対する保存も同じである。

418 :仕様書無しさん:2016/09/24(土) 00:37:24.60
>>416
脊髄レスかよ・・・

419 :仕様書無しさん:2016/09/24(土) 00:39:24.66
>>414
VB4だったので使えませんでした

420 :仕様書無しさん:2016/09/24(土) 00:40:30.81
>>419
インターフェイスが

421 :仕様書無しさん:2016/09/24(土) 09:35:09.59
SI受注SEの知的財産と契約料金の搾取対策

早死に貧困の助長だから偽装請負の従犯は辞めろ!
相場下がって迷惑だから報酬増やすか作業減らせ!

・IT社長に贅沢資金を搾取させるな
・客先経営資金削減の犠牲になるな
・平均年齢40歳未満の会社は辞めろ
・6時間/日以上PC使用の会社は辞めろ
・1,000万円/年以下の会社は辞めろ
・100万円/月以下の契約は辞めろ
・5,000円/時以下の契約は辞めろ
・100万円/月以下のプログラムは作るな
・偽装請負の開発は辞めろ
・多重派遣の開発は辞めろ
・多重契約は辞めろ
・残業見積りは止めろ
・不要作業は止めろ
・時間外労働違反は止めろ
・契約外作業期日は守るな
・客先指示に従うな
・不利益な依頼は断れ
・知的財産を渡するな
・生産効率を上げろ
・残業しないで学習しろ
・残業しないで副業しろ
・損害は訴えろ

【非婚】受注SEは3億円以下の低生涯収入【離婚】
http://hanabi.2ch.net/test/read.cgi/infosys/1473857318/

422 :仕様書無しさん:2016/09/24(土) 12:17:57.34
例外だけを専門に扱った本とか無いのか?
ネットの連中じゃ役に立たないわ

423 :仕様書無しさん:2016/09/24(土) 12:37:20.18
>>422
例外のなにが難しいんだよw

424 :仕様書無しさん:2016/09/24(土) 13:59:32.44
チェック例外と非チェック例外のどちらを投げるべきか
例外をラップすべきかそのまま投げるべきか
自前の例外クラスを作るべきか
例外をどこでキャッチすべきか
例外にすべきか戻り値にすべきか
リカバリ対象の例外を選ぶべきか有無をいわさずキャッチしてリカバリするか

もう山ほど

このときはこうしろ!ってセオリーがないし
ライブラリもめいめい勝手な例外投げてくるもんだからカオス

425 :仕様書無しさん:2016/09/24(土) 14:03:07.91
>>419
> VB4だったので使えませんでした

ならあんたには旧VBで誰がやっても同じになるなんて
言えないはずだよね。

426 :仕様書無しさん:2016/09/24(土) 14:06:28.09
>>424
チェック例外と非チェック例外があるのはJavaぐらいなんだから
それについてはほとんどの言語で考える必要はないこと。

タブにするかスペースにするか程度の問題だよ。
プロジェクトの好みで決めればいい。

ただひとつ言っておくと、チェック例外を使うならば
ルールが増えるっていうこと。面倒だよね。

で例外をキャッチする場所なんて明確にわかることなので
議論する必要はない。

例外の問題は、例外の正しい使い方を知らないやつがいるってだけ。
知らないやつがギャーギャー騒いでいるだけ。
例外の正しい使い方を知っているならば、誰でも同じようになる。

427 :仕様書無しさん:2016/09/24(土) 14:10:38.32
>>424
議論され尽くしてベストプラクティスが出来上がってることばかりいまさら問題にしてんだな、お前ってw
20年前からやってきたのか?

428 :仕様書無しさん:2016/09/24(土) 14:12:48.68
>>425
誰がやっても比較的同じになりやすい

これを、誰がやっても同じになる、と解釈して噛みつく奴ってw

429 :仕様書無しさん:2016/09/24(土) 14:20:40.90
議論されつくされてるなら本の一冊もあるもんだろう
こうだ!って主張するやつも言うことが抽象的だし

>例外の問題は、例外の正しい使い方を知らないやつがいるってだけ。
挙句にこんな無意味の極みみたいなことしか言わんし

430 :仕様書無しさん:2016/09/24(土) 14:23:09.38
>>429
まぁええわ
お前はそこで立ち止まってろ

431 :仕様書無しさん:2016/09/24(土) 14:36:36.83
プログラミング歴の浅い人には例外は難しいかもね

432 :仕様書無しさん:2016/09/24(土) 15:09:20.70
いんや、現場見てると昔人間の方が頭ひねってるよ
もしくは何の疑問も持たず間違った使い方をしてる

オブジェクト指向から入った若いやつらにとっては、例外は例外でしかない

433 :仕様書無しさん:2016/09/24(土) 15:18:56.76
>>428
> これを、誰がやっても同じになる、と解釈して噛みつく奴ってw

噛み付いてるのはそこじゃねーよw

VBも他の言語も大差ないって話をしてる。
言語によって同じになりやすいとかあるわけないだろ

434 :仕様書無しさん:2016/09/24(土) 15:20:26.47
>>429
> 議論されつくされてるなら本の一冊もあるもんだろう
議論するほどの量がない。

> 挙句にこんな無意味の極みみたいなことしか言わんし
事実なんだから仕方ないだろ。例外でぎゃーぎゃー騒いてるやつは
例外をだめな技術にしたいから、話を聞かない。

435 :仕様書無しさん:2016/09/24(土) 15:42:53.14
>>433
VBを語るのに言語だけ切り取っても意味ないよ。
もちろん汎用言語としても使えるけど、ほとんどの文脈で、VBとはVSでGUIアプリを作るための言語だから。

> VBも他の言語も大差ないって話をしてる。
> 言語によって同じになりやすいとかあるわけないだろ

汎用言語としては他の言語と大差ないとしても、VS用言語としてのVBは誰がやっても同じになりやすい。
わかった?もう知ったかしてわかったようなこと言うなよ?

436 :仕様書無しさん:2016/09/24(土) 15:55:54.62
>>435
だからならないって言ってる。
その根拠として、クラスモジュールとインターフェースを
どのように使っているか聞いたんだが?

VB4だったので使えませんでしたという回答から結論を導き出すならば、
VB6では、使ってる人と使ってない人(VB4のやり方をしてる人)がいるってことだろ。

437 :仕様書無しさん:2016/09/24(土) 16:14:55.27
誰が書いても似たような作りになるって言われてたのってPythonだっけか

438 :仕様書無しさん:2016/09/24(土) 16:15:59.45
生粋のVBラーとコボラーはロジックの組み方に独特のクセがある気はする
そういう奴が書いたVBのソースは誰が書いても似てるっちゃ似てる

439 :仕様書無しさん:2016/09/24(土) 16:21:06.82
>>437
> 誰が書いても似たような作りになるって言われてたのってPythonだっけか
それも実体験で、そうはならないとわかった。

経験が浅いプログラマ(一年程度)が書いたコードを見たが
Pythonらしさなんか皆無なコードで、処理があちこちに分散されていて
構造と呼べるものがまったくなかった。

所詮インデントを矯正するだけじゃ似たような作りになるわけ無いと思ったよ。

440 :仕様書無しさん:2016/09/24(土) 16:22:55.59
>>438
> 生粋のVBラーとコボラーはロジックの組み方に独特のクセがある気はする

その理屈から言えば、生粋のVBラーではない人が
VBでコードを書いたら、別物になるって言ってるようなもんなんだがw

まあ事実だけどね。誰が書いても同じ書き方になる言語はない。

441 :仕様書無しさん:2016/09/24(土) 17:15:27.93
自由がない言語ほど似たような書き方になる可能性が高い

例えば、同じことを実現するコードの書き方が3通りある言語と5通りある言語では後者のほうが書き方がばらつく
CとC++であれば、C++のほうが多機能な分、同じことを実現するコードであっても書き方がよりばらつく

442 :仕様書無しさん:2016/09/24(土) 17:23:43.57
VSでGUIアプリを作ると、VSという環境によるサポート(逆に言うと制限)があるので、誰がやっても似たような作りになりやすい
HTML5とJSでSPAを作るのと作り方のばらつきは同程度だと思ってるアホもいるようだが

443 :仕様書無しさん:2016/09/24(土) 17:38:35.69
例外てのは基本の処理から外れた事態に対して
対応する処理を書くためのもんだ

444 :仕様書無しさん:2016/09/24(土) 17:40:24.28
つまり例外は例外処理をどれくらい書けるかで
使えてるかどうかが判る
ログだして対応完了てのは、使えてるとは言わん

445 :仕様書無しさん:2016/09/24(土) 18:18:22.46
たかがlongjumpに例外なんていう絶妙にどうとでもとれる名前を付けちゃったから
意固地な人達がその意味を巡って宗教論争を始めちゃうっていう
そして、ひとだび例外が使われているのを見つけるとそういう人達は
無垢なる子羊を自分の宗派に引き込もうとなんやかんやと大して意味もないお説教を始めるw
これによりプログラムを学ぶ人達はひょっとして例外とはとてつもなく難しい事なのではないか?
という錯覚に落ちいり世間に「例外は難しい」風説が流れる
たかがlongjumpなのにw

446 :仕様書無しさん:2016/09/24(土) 20:20:07.35
>>445
ロングジャンプはただの実装だろ?
例外という概念にどう対処するかを論じている

447 :仕様書無しさん:2016/09/24(土) 22:38:15.23
概念はlongjump
例外は名前だろ?

448 :仕様書無しさん:2016/09/24(土) 22:46:02.96
ロングジャンプは「ただし〜の場合は例外」を表現するための一手段に過ぎないだろ?

449 :仕様書無しさん:2016/09/24(土) 22:53:35.12
例外=GOTOである
GOTOは諸悪の根源である
であるから、例外は使ってはならない

450 :仕様書無しさん:2016/09/24(土) 22:54:33.68
なんで名前が先なんだよw
てかお前んとこの例外はthrowする以外にも芸があるのか?

451 :仕様書無しさん:2016/09/24(土) 23:02:00.53
>>450
C言語等では関数の戻り値によって成否をチェックしてきた
例外処理はそういった異常処理を一括で行う仕組みを提供しているだけだ

例外処理の概念は今も昔も基本的に変わらないということ。

452 :仕様書無しさん:2016/09/24(土) 23:10:21.46
やっぱり名前に影響されて変な先入観持ってるな
×:例外処理はそういった異常処理を一括で行う仕組みを提供している
○:longjumpという概念がエラー処理を簡略化するのに便利に使えた
こうやでw

453 :仕様書無しさん:2016/09/24(土) 23:13:14.98
あ忘れてた
それよりもthrow以外の芸早くおしえろ下さいw

454 :仕様書無しさん:2016/09/24(土) 23:19:17.37
チェック例外はその場でチェックして
どうしていいか分かんないものは全部RuntimeExceptionでラップしてぶん投げる

それが俺のベストプラクティス

455 :仕様書無しさん:2016/09/25(日) 01:09:02.18
>>454
Javaの話だよね。
チェック例外に振り回されて、そこら中のメソッドに"throws"をつけるよりも
そっちの方がすっきり綺麗だわな。
よくあるのは、URIを扱うクラスでの例外とかね。
そうやってラップしてthrowしておけば、万が一何かあってもすぐに気づく。
酷いのは、catchして無視するか、e.toString()をprintするだけ。(やめて)

456 :仕様書無しさん:2016/09/25(日) 01:11:11.84
そういえばcatchからgotoでtry内に戻るコード書いてるやつ居たわ。
//なんかたまにエラー出る
って書き添えてあった。

457 :仕様書無しさん:2016/09/25(日) 08:41:18.84
例外といえばよく見るのが

throw ex

これだな
これがダメだとわかってないやつ多すぎ

458 :仕様書無しさん:2016/09/25(日) 08:45:17.61
>>457
具体的な例をおながいします、師匠!

459 :仕様書無しさん:2016/09/25(日) 09:35:18.16
>>458
一言で言えば

例外は投げるな、返せ

これがわからなければプログラマ辞めた方いい

460 :仕様書無しさん:2016/09/25(日) 10:35:55.14
>>459
そんな一言で終わらさずに、もっと具体的な例でお願いします!

461 :仕様書無しさん:2016/09/25(日) 10:40:03.46
技術屋の家族かわいそう

技術ない方が収入と寿命高いって有り得ないだろ!
相場下がって迷惑だから収入上げるか技術下げろ!

放送・商社・銀行・公務 > 製造・化学・通信・情報

2014年度有価証券報告書より
伊藤忠商事 1,395万円(41.5歳)
三菱商事  1,376万円(42.6歳)
三井物産  1,361万円(42.4歳)
丸紅    1,306万円(41.5歳)
住友商事  1,301万円(42.8歳)

http://m.finance.yahoo.co.jp/stock/fundamental?code=4676.T

462 :仕様書無しさん:2016/09/25(日) 11:26:36.23
>>456
かわいい

463 :仕様書無しさん:2016/09/25(日) 13:25:31.36
>>459
either使えってこと?

464 :仕様書無しさん:2016/09/25(日) 15:11:48.92
>>459
例外を返す?なに言ってんだ?

465 :仕様書無しさん:2016/09/25(日) 15:24:36.51
>>437
というよりPythonはPython自身がPythonらしさを求める。
Pythonでちゃんと書こうとするとき、自分の好みの書き方よりPythonらしく書けてるか?を気にするようになる。

466 :仕様書無しさん:2016/09/25(日) 15:37:27.36
気にするようになるってことは、
気にするようになるまではPythonらしいコードじゃないということ。

だからPython使っても人によって
書き方が違うということでもある。

467 :仕様書無しさん:2016/09/25(日) 16:03:09.75
>>466
そりゃそうだよw
そんなの大前提なんだから、得意気にドヤんなくていいよw

468 :仕様書無しさん:2016/09/25(日) 17:29:15.99
なぜ大前提を書いただけなのに
そんなに過剰反応してるの?

469 :仕様書無しさん:2016/09/25(日) 17:41:35.18
基本的な内容を表現するに当たり、極めてドヤ表現が強い文を形成したからだと思われます。

470 :仕様書無しさん:2016/09/25(日) 17:51:13.78
>>457←こいつアホやろw

471 :仕様書無しさん:2016/09/25(日) 21:58:00.72
>>470
とりあえずVisualStudioのコード分析かけてみろ

472 :仕様書無しさん:2016/09/25(日) 22:03:14.61
会話が停滞するからさっさと結論まで言わんかいw

473 :仕様書無しさん:2016/09/25(日) 22:07:58.21
こんだけいじられたらもう何も言えんやろ逆にw

474 :仕様書無しさん:2016/09/27(火) 08:12:22.20
「偽装請負」にご注意ください!

*「偽装請負」とは・・・
 書類上、形式的には請負(委託)契約ですが、実態としては労働者派遣であるものを言い、違法です。
*請負と労働者派遣の違いは・・・
 請負とは、「労働の結果としての仕事の完成を目的とするもの(民法)」ですが、派遣との違いは、発注者と受託者の労働者との間に指揮命令関係が生じないということがポイントです。
*労働者の方から見ると・・・
 自分の使用者からではなく、発注者から直接、業務の指示や命令をされるといった場合「偽装請負」である可能性が高いと言えるでしょう。
*「偽装請負」は・・・
 労働者派遣法等に定められた派遣元(受託者)・派遣先(発注者)の様々な責任が曖昧になり、労働者の雇用や安全衛生面など基本的な労働条件が十分に確保されないという事が起こりがちです。

偽装請負の代表的なパターン
<代表型>
 請負と言いながら、発注者が業務の細かい指示を労働者に出したり、出退勤・勤務時間の管理を行ったりしています。偽装請負によく見られるパターンです。
<形式だけ責任者型>
 現場には形式的に責任者を置いていますが、その責任者は、発注者の指示を個々の労働者に伝えるだけで、発注者が指示をしているのと実態は同じです。単純な業務に多いパターンです。
<使用者不明型>
 業者Aが業者Bに仕事を発注し、Bは別の業者Cに請けた仕事をそのまま出します。Cに雇用されている労働者がAの現場に行って、AやBの指示によって仕事をします。一体誰に雇われているのかよく分からないというパターンです。
<一人請負型>
 実態として、業者Aから業者Bで働くように労働者を斡旋します。ところが、Bはその労働者と労働契約は結ばず、個人事業主として請負契約を結び業務の指示、命令をして働かせるというパターンです。
http://tokyo-roudoukyoku.jsite.mhlw.go.jp/hourei_seido_tetsuzuki/roudousha_haken/001.html

475 :仕様書無しさん:2016/09/27(火) 08:20:10.57
>>466
その言語らしさってのが気になるようにならない言語もあるんですよ。

476 :仕様書無しさん:2016/09/27(火) 19:40:19.13
pythonは誰が書いてもpythonらしくなるけどな
一部の無能を除いてだけど
つーか無能の場合どんな言語を使ってもそもそもプログラムらしくならんしw

477 :仕様書無しさん:2016/09/28(水) 00:07:38.99
インデントが同じだから見た目が似てるだけじゃないの?

478 :仕様書無しさん:2016/09/28(水) 07:39:29.17
マ板なのにコードを書かない不思議

479 :仕様書無しさん:2016/09/28(水) 08:20:06.64
偽装請負・多重派遣被害

偽装請負とは、実際は人材を派遣して利益を得ているにも関わらず、業務請負など別の契約形態で労働者を働かせることを言います。

IT業界では昔から「偽装請負」が蔓延しており、知らないで被害者になっているプログラマーやSEがいます。

●労働者派遣法違反
●職業安定法第44条違反
●労働基準法第6条違反
に該当します。

●労働者派遣法違反
事前面接は労働者派遣法の「対象業務外労働者派遣罪」を構成し、また、罰則が派遣元(派遣業者:法人も処罰する両罰規定)適用されます。派遣先については、派遣元に対象業務外派遣を教唆したり、幇助したときには、共犯(教唆犯または幇助犯)の刑事責任が問われます。

●職業安定法違反
さらに、対象業務外の労働者派遣は、職業安定法第44条が禁止する「労働者供給」に該当しますので、派遣元は供給元として「労働者供給罪」、派遣先は供給先として「労働者受供給罪」を犯すことになり、それぞれ罰則を適用されます。
職業安定法第44条(労働者供給事業の禁止)
何人も、次条に規定する場合を除くほか、労働者供給事業を行い、又はその労働者供給事業を行う者から供給される労働者を自らの指揮命令の下に労働させてはならない。
この職業安定法第44条違反の行為については、職業安定法第64条で、1年以下の懲役又は100万円以下の罰金に処せられると定められています。

●労働基準法違反
就業にあたって第三者が利益を得ることは「中間搾取」として労働基準法で厳しく禁止されています。違反には、罰則も同法第118条で「1年以下の懲役又は50万円以下の罰金に処」せられることになります。

http://www.roudousha.net/keiyaku/090_gisouukeoi.html

480 :仕様書無しさん:2016/09/28(水) 12:17:46.96
>>477
PythonはPythonらしいコードが読みやすくて良いコードになるように言語設計してるんだよ
インデントもその方針の実現方法の一つだね
他の言語はその言語らしさを保ったり改善することより、その言語で何が出来るか性能がどうかが優先される気がするね。

481 :仕様書無しさん:2016/09/29(木) 10:16:47.26
【犯罪者追放のお願い】

違法派遣(偽装請負・多重派遣・偽装出向・事前面接等)についての刑事罰
【告訴権者=業務委託、準委任、共同受注、業務請負契約および特定派遣(契約・正規)、一般派遣、正規社員】

@職業安定法第44条の労働者供給事業の禁止規定に違反(1年以下の懲役または20万円以下の罰金)
 ■偽装請負・多重派遣・偽装出向・多重出向
 ■事前面接(顔合わせ・面談・職場見学等)と履歴書・職務経歴書・スキルシート等提出による労働者の特定(※)
(音声録音で立証可能)
A労働基準法第6条(中間搾取の禁止) (1年以下の懲役又は50万円以下の罰金)
 ■多重派遣・多重出向

※違法派遣(派遣労働者の特定)→派遣法で認められた派遣労働者ではない→労働者供給事業→職業安定法44条違反というの
が前提となる法解釈となります。派遣法における罰則が軽微なのは法律の不備や労働者軽視などが原因ではありません。
違法派遣は全て職業安定法44条で裁くことが可能なため、刑罰の重複を避けるために派遣法には軽微な罰則(主に裁量行政による)しかないのです。

使用者に有利な民事訴訟や労働関係諸局への通報等の対極にあるのが書面(告訴状)による刑事告訴(※告訴先は検察の直告班)です。
労働関係諸局への通報・斡旋による軽微な「適正化」や監督・指導に対して、法律に定められた刑事罰を問うことになり、
違法派遣業者にとって有罪は考えられる限り最大の処罰となります。同時に刑事罰を受けた
担当者が取引先に与える悪印象を考慮すれば、通常会社側は告訴が受理された時点で告訴取り下げに
動くのが妥当でしょう。懲役、前科がつく刑罰が下される可能性から、告訴取り下げの和解金は高額となることが多いのです。

告訴の流れとしては、
刑事告訴⇒告訴受理⇒告訴取下げ要請⇒取下げ和解金入金⇒告訴取下げ
となります。告訴の懲役刑適応は犯罪者個人に対してのみですので、告訴する対象は
派遣先・派遣元 社員
派遣先・派遣元 社長
派遣先・派遣元 担当者・責任者・管理役員・取締役
派遣先・派遣元 人事管理担当者・人事管理役員・取締役
が妥当です。
刑事告訴取り下げの和解金額は犯罪者個人と交渉するとよいでしょう。(告訴状は人数分提出する必要あり)

482 :仕様書無しさん:2016/09/29(木) 20:24:42.07
>>478
そりゃ、プログラマ板だからだよ

つ プログラム技術板

483 :仕様書無しさん:2016/09/29(木) 21:32:56.65
ここって技術の無い連中が見下すための板だしな

484 :仕様書無しさん:2016/09/29(木) 22:15:21.56
その技術ってやつを一度でも見せてくれたら俺も見下さずに済むんだけどな

485 :仕様書無しさん:2016/09/29(木) 22:39:26.84
プログラムセンスとコーディングセンスは別物

コーディングセンスにプログラムセンスはいらないけど
プログラムセンスにコーディングセンスは不可欠

小説家のような様々な表現を巧みに使いこなす人と
定型文のような文章をきっちり書く人の違い

コーディングセンスがあるからといってプログラムセンスがあるとは限らないけど
プログラムセンスがある人はコーディングセンスもある

486 :仕様書無しさん:2016/09/29(木) 22:41:16.89
1℃

487 :仕様書無しさん:2016/09/29(木) 23:01:39.77
>>485
>小説家のような様々な表現を巧みに使いこなす人と

いやぁぁああぁあああ

488 :仕様書無しさん:2016/09/30(金) 00:16:12.98
>>478
俺らのコードはけっこう高いんだよ
計算してみたら1行1000円〜2000円ぐらいだよ

489 :仕様書無しさん:2016/09/30(金) 00:35:32.48
高度

490 :仕様書無しさん:2016/09/30(金) 07:57:34.26
>>488
「ステップ数どれくらい?」(笑)

491 :仕様書無しさん:2016/09/30(金) 10:32:48.24
【犯罪者追放のお願い】

犯罪者個人に対して告訴状を偽装請負・偽装出向・多重派遣の被害者が作成(刑事告訴は無料) or 司法書士が代筆(料金は5万円ぐらい)

告訴状を【検察の直告班】に郵便局の内容証明付で送付(疎明資料・証拠にはICレコーダー、スマホによる録音が適しています)

審査 → 不受理 → 告訴状再提出または刑法 第193条で訴えを起こす

受理 → 告訴事実を認め示談交渉(↓) →示談成立  →法廷相場50〜100万円の示談金 ※示談拒否が良い
↓                ↓
事案化 ←←←←←← 示談不成立(↓) →示談外交渉 →犯罪者の年収半額×最大懲役年数の和解金支払い※推奨
↓                ↓
↓               起訴  →公判  →罰金刑=前科(起訴事実を認めてるため)→追討ち民事訴訟
↓                    
審査 → 起訴(強制捜査・留置場)→ 公判 → 懲役刑などの厳罰(反省が認められないため)→追討ち民事訴訟

不起訴、起訴猶予

検察審査会法第30条(検察審査会へ申し立て)→ 起訴 → 起訴後は同上
刑法 第193条(公務員職権濫用)で検察事務官を刑事告訴 → 同上

◎告訴→告訴受理→示談交渉→厳罰を求め示談不成立→示談外交渉→和解金支払い・和解契約(公正証書・即決和解で秘密保持契約)
◎偽装請負・出向・違法派遣事件では派遣・出向先両方の代表者、役員、現場責任者に告訴できます。
前科がついた犯罪者が法人の代表であれば公的な入札からの排除、取引先や顧客との契約解除など社会的制裁・批判に晒されることから辞職または解任が妥当、役員・社員であれば懲戒を想定。
◎事業者内部の加害関係者による刑事告発(刑事訴訟法239条1項)も可能です。
加害者本人、管理間接部門の社員が刑事告発に踏み切る場合も和解金による解決が妥当です。

注意:告訴が受理されない理由
●3年間(※)の時効が過ぎたもの ※違法派遣
●同一事実について過去に告訴取消しがあったもの
●関連する民事訴訟を有利に導く目的の場合
●証拠が希薄なもの ※被害者が契約時に違法派遣・偽装請負・多重派遣と知っていても刑事告訴は有効です。

492 :仕様書無しさん:2016/09/30(金) 20:31:02.47
>>477
他の言語は同じ機能を実装するのでもいくつも書き方があるけどpythonはそこの数を絞ってるから誰のコードも同じに見えるようになってる

493 :仕様書無しさん:2016/09/30(金) 21:07:25.21
> pythonはそこの数を絞ってるから
これ嘘だろうねw

比較図とか見たことないし。

494 :仕様書無しさん:2016/09/30(金) 21:11:06.35
>>492はだいたい正しいと思うよ
rubyは真逆だもんね

495 :仕様書無しさん:2016/09/30(金) 21:12:18.29
Python のリファクタリングでイケてないコードを別に美しいオブジェクト指向設計ではない普通のコードにする方法
http://qiita.com/methane/items/fa5f9c9c31f7afcf2211

> これは Python だと filter か内包表記にするところです。
filterと内包表記の二つのやり方があります。

> Python の場合は inject の代わりに reduce があるのですが、あまり使いません。こういう場合は素直に sum を使います。
reduceとsumの二つのやり方があります。



まあね、誰が書いても同じというのなら、リファクタリングなんする必要が無いはずだよ。
コードの可読性とかを調べるツールも必要ないはずだよ。

当たり前だけど誰が書いても同じようなコードになるわけないんだだよね。

496 :仕様書無しさん:2016/09/30(金) 21:13:35.05
http://www.yoheim.net/blog.php?q=20160612

> PEP8(Python用スタイルガイド)では、前提となる考え方があります。それは、
> 一貫性にこだわりすぎるのは、狭い心の現れである


(・∀・)ニヤニヤ

497 :仕様書無しさん:2016/09/30(金) 21:14:46.13
こっちにリンクするべきだったね。

一貫性にこだわりすぎるのは、狭い心の現れである
https://pep8-ja.readthedocs.io/ja/latest/

498 :仕様書無しさん:2016/09/30(金) 21:17:18.15
ホント、コード書いて競わないんだね
マじゃなくてSEが多いの?

499 :仕様書無しさん:2016/09/30(金) 21:21:36.03
コードを書いて競うのはマじゃなくてダーですがw

500 :仕様書無しさん:2016/09/30(金) 22:08:03.44
コード出すと過疎スレになるからなw
仕事以外でもコードを見ていたいやつは減った気がするね
なんというか優秀な変人をあまり見かけなくなった
スポーツマンでイケメンで頼れるタイプばかり

501 :仕様書無しさん:2016/09/30(金) 22:21:29.99
>>500
コボラーはすっこんでろカスw

502 :仕様書無しさん:2016/09/30(金) 22:24:45.05
>>501
そんな虚勢はってていいの?9を並べちゃうよ?

503 :仕様書無しさん:2016/09/30(金) 22:27:03.97
9屈なスレ

504 :仕様書無しさん:2016/09/30(金) 22:29:51.63
>>502
俺はコボラーちゃうわw

505 :仕様書無しさん:2016/09/30(金) 22:37:29.35
おまえら電話のメモをCOBOLコーディングシートに書くのやめろw

506 :仕様書無しさん:2016/09/30(金) 22:42:22.70
ちょっと面白かったw
ちょっとだけだぞ俺はコボラーちゃうで

507 :仕様書無しさん:2016/09/30(金) 22:45:18.33
実際、コーディングシートはメモ書きにちょうどいいからな
ちょっとサイズ大きいけど

508 :仕様書無しさん:2016/09/30(金) 23:11:55.39
あっと言う間にコーディングシートって使わなくなった
ジョブフローを書く5_方眼は残った

509 :仕様書無しさん:2016/10/01(土) 04:01:57.45
俺の中でセンスある人は再起処理を上手く使える人かな。
未だによくわかんねーし一回も使ったことない。

510 :仕様書無しさん:2016/10/01(土) 07:50:03.96
ツリー構造を下るときに良く使う

511 :仕様書無しさん:2016/10/01(土) 10:06:05.25
"再起"じゃなくて"再帰"だお(釣り?)

確かに、俺が扱うアプリでは、階層データ構造で再帰はよく使うけど、
何度もやってるうちに、精神がマジでやられるから、
最近はユーティリティを作って、再帰を利用側から隠蔽するようにしてる

親子関係を無くし、全てフラットなリストで返したり(個々のdepthやparentも参照できる)
検索条件をpredicateとして渡せるようにしたりして

512 :仕様書無しさん:2016/10/01(土) 12:17:15.58
別に普通だな

513 :仕様書無しさん:2016/10/01(土) 12:20:21.17
再帰に再起不能にされた人

514 :仕様書無しさん:2016/10/01(土) 13:12:01.74
>>512
>>511書いたけど、自分でも普通だと思う
ボクには特別なセンスがあるんだお!と思って書いたわけじゃなくて
昔C#でそんなことやってる外人ブログを見つけて、それを真似しただけ

515 :仕様書無しさん:2016/10/01(土) 13:17:50.73
再帰でメンタル壊れるなんて聞いたことないぞ

516 :仕様書無しさん:2016/10/01(土) 15:45:37.57
システム開発裁判アドバイス

裁判は、申し立て書を提出するだけでシステム開発よりも簡単に行えます。

システム開発の特許権・著作権・報酬等の料金請求をする際は、以下の理由から開発技術の立証をするべきです。
・契約技術の争点でなく契約解釈の争点となってしまう
・契約技術の料金でなく契約解釈の料金になってしまう
・低技術開発ほど得して高技術開発ほど損してしまう
・能力が高い技術者が報われなくなってしまう
技術判定は、裁判所でシステム開発内容を鑑定してもらって下さい。裁判官は、システム開発に精通してないため裁判所の専門委員が対応します。

システム開発裁判の主張・立証は、以下の背景から弁護士に委任するよりも技術者自身が本人裁判をする事をお勧めします。
・開発技術に精通した弁護士が不足している
・開発技術の把握が弁護士業務かの判別も曖昧である
・開発技術の立証は弁護士の適性として困難である
・開発技術の内容を弁護士に説明するのは困難である
従って弁護士と依頼者の双方に負担となってしまいます。

システム開発訴訟の審理
www.courts.go.jp/vcms_lf/20901004.pdf

517 :仕様書無しさん:2016/10/01(土) 16:19:25.97
>>515
終了条件が不安定だと壊れるだろ

518 :仕様書無しさん:2016/10/01(土) 19:29:33.87
終了条件が不安定なものを再帰にするな
背後に迫るスタックオーバーフローを常に意識しろ

519 :仕様書無しさん:2016/10/01(土) 19:29:57.31
当たり前の事のように言ってるとこがちょっと怖い

520 :仕様書無しさん:2016/10/01(土) 21:14:52.96
再帰じゃなきゃ実装できない処理って、あんま無いよね

521 :仕様書無しさん:2016/10/01(土) 21:46:13.44
言語によるんじゃね?
Erlangだと基本再帰。
cやらjavaだと再帰つかう場面はかぎられる。
ほかの関数型言語つかったことないけど、どーなんだろ。

522 :仕様書無しさん:2016/10/01(土) 22:21:43.08
> Erlangだと基本再帰。

それは、再帰じゃなきゃ実装できない処理じゃなくて
再帰じゃなきゃ実装できない言語

そりゃループをするために必要な機能が欠けてるんじゃ
再帰しか出来ないだろうねw

523 :仕様書無しさん:2016/10/01(土) 22:22:13.45
>>509
再起やSQLが得意だけど
他の人が読めなくなるからあんま使わないようにしてるよ
特に再起はバグったときに変なことになるからコーディング規約で禁止してるとこも多いね

524 :仕様書無しさん:2016/10/01(土) 22:44:07.66
これならコーディング規約で禁止されてても回避できるかなw
#include <stdio.h>
typedef int (*CB)(void *, int);
int fact(void *callback, int n)
{
if (n == 0)
return 1;
return n * ((CB)callback)(callback, n - 1);
}
int main()
{
printf("%d\n", fact(fact, 10));
return 0;
}

525 :仕様書無しさん:2016/10/01(土) 22:52:24.23
いろいろとキモい

526 :仕様書無しさん:2016/10/01(土) 23:16:15.71
え?まさかまたコボラーか?w

527 :仕様書無しさん:2016/10/01(土) 23:25:34.62
これがYコンビネーター…!!

528 :仕様書無しさん:2016/10/01(土) 23:25:50.69
>>523
SQLを使うのに得意も何も無いだろ
それともORマッピング使うってこと?

529 :仕様書無しさん:2016/10/01(土) 23:31:36.62
>>528

>>523じゃないけど、SQLっていうのは
高度に完成された宣言型・関数型言語ですよ。

530 :仕様書無しさん:2016/10/01(土) 23:57:25.23
ものにもよるが、プログラミングよりSQLで書いた方が早いとか断言しちゃう奴は要注意人物
「パフォーマンスが〜」とか言ってSQLの関数使用を無条件に禁止する奴は、さらに要注意人物、ってか現場から排除したい

531 :仕様書無しさん:2016/10/02(日) 00:12:27.68
SQL使いたいのか使いたくないのかよくわからん奴だな

532 :仕様書無しさん:2016/10/02(日) 00:18:08.39
>>529
難しいクエリ書くなってなら判るんだよ

533 :仕様書無しさん:2016/10/02(日) 00:19:22.44
>>531
どっちも、頭の中にロジックが描けない奴だから要注意ってこった
前者は少なくともSQLが書ける程度ではあるが、後者は全くの無能どころか害悪

534 :仕様書無しさん:2016/10/02(日) 00:22:45.75
>>533
いやむしろ書ける程度がお前なのだと思ったけど

535 :仕様書無しさん:2016/10/02(日) 01:09:12.86
>>532
何を言ってるんだお前は?
難しいかどうかなんて関係ないだろ。

目的はユーザーの仕様を満たすことであって、
難しいクエリになるから実現できませんじゃないんだよw

536 :仕様書無しさん:2016/10/02(日) 01:19:10.50
逆も然りだろ
クエリ云々はどうでもいい
実現可能ならSQLにこだわる必要は無い

537 :仕様書無しさん:2016/10/02(日) 01:24:44.01
SQL以外でRDBMSから効率的に少ないコードで
データを取ってくる方法を教えてほしいものなんだがw

538 :仕様書無しさん:2016/10/02(日) 01:41:40.94
暗に、RDBMSにこだわる必要は無いとも言ってるんだが

539 :仕様書無しさん:2016/10/02(日) 05:07:06.17
>>535
ユーザの仕様?

ユーザって誰よw

特定の業界の話されても困るなあ

540 :仕様書無しさん:2016/10/02(日) 05:42:53.43
アセンブリとかSQLは可読性を気にする必要がないものだよ
速度が正義

サーバー設定全般に関わってくるからそういう意味ではSQLはプログラマの仕事ではない

541 :仕様書無しさん:2016/10/02(日) 06:02:36.55
SQLとRDBMSの違いを意識しないバカ発見

542 :仕様書無しさん:2016/10/02(日) 07:56:24.23
>>535
君何言ってるのかよくわかんない。
SQL書けないんならPG辞めちまえ。

543 :仕様書無しさん:2016/10/02(日) 08:07:49.72
罵倒する時も律儀に句点を打つのだ。

544 :仕様書無しさん:2016/10/02(日) 09:30:11.84
>>540
アセンブリ言語は、もう少しわかりやすくしてもいいかもね。

545 :仕様書無しさん:2016/10/02(日) 10:25:11.97
>>542
なんで俺に言うんだ?馬鹿かw

SQLで簡単にかけるものをその他の方法を使うと
効率悪いし、可読性も悪くなるって話をしてるんだが。

546 :仕様書無しさん:2016/10/02(日) 10:26:40.38
受注SEの知的財産と契約料金の搾取対策

早死に貧困の助長だから偽装請負の従犯は辞めろ!
相場下がって迷惑だから報酬増やすか作業減らせ!

・IT社長に贅沢資金を搾取させるな
・客先経営資金削減の犠牲になるな
・平均年齢40歳未満の会社は辞めろ
・6時間/日以上PC使用の会社は辞めろ
・1,000万円/年以下の会社は辞めろ
・100万円/月以下の契約は辞めろ
・5,000円/時以下の契約は辞めろ
・100万円/月以下のプログラムは作るな
・偽装請負の開発は止めろ
・多重派遣の開発は止めろ
・多重契約は止めろ
・残業見積りは止めろ
・不要作業は止めろ
・時間外労働違反は止めろ
・契約外作業期日は守るな
・客先指示に従うな
・不利益な依頼は断れ
・知的財産を渡するな
・生産効率を上げろ
・残業しないで学習しろ
・残業しないで副業しろ
・損害提訴を怠るな

【非婚】受注SEは3億円以下の低生涯収入【離婚】
http://hanabi.2ch.net/test/read.cgi/infosys/1473857318/

547 :仕様書無しさん:2016/10/02(日) 10:44:00.65
難しいSQL書くなとか言っちゃう人はやっぱりプログラムセンスがないんだろうなあ

548 :仕様書無しさん:2016/10/02(日) 11:06:49.75
たまに何でもSQLに詰め込もうとする奴居るだろ。
取ってきたデータ加工するほうが簡単なのに。

549 :仕様書無しさん:2016/10/02(日) 11:09:38.84
SQLは保守性、拡張性が高くはないので、ややこしい処理はあまりやらせない方が後で楽。

とはいえ、結合や副問合せで5テーブル程度まとめたくらいで難しいとか言うやつは、たしかにセンス無い。
ていうかセンス以前にスキルが無い。

550 :仕様書無しさん:2016/10/02(日) 11:12:23.46
だいたいクエリで何でもやろうとするやつはインデックス意識してないだろ。
そんな複雑なクエリじゃフルスキャンになっちゃうよ。

551 :仕様書無しさん:2016/10/02(日) 11:13:17.61
>>548
そうか?ヘタクソかつ中途半端なSQLは山ほど見てきたけど
SQLでそこまでやるか?ってのには未だにお目にかかった事がない

552 :仕様書無しさん:2016/10/02(日) 11:15:23.73
どの層で加工すべきかが重要だ
簡単だから〜とかマジ浅はか
例えば、日付フォーマットをSQL側でやろうとする人は、
その辺がなんにも分かってない

553 :仕様書無しさん:2016/10/02(日) 11:17:06.12
>>550
複雑だからと言って、そう簡単にはならない
実行計画を考慮して、開発するのは当たり前

554 :仕様書無しさん:2016/10/02(日) 11:17:12.45
>>552
小難しい事言う奴は「アーキテクチャ宇宙飛行士」と呼ばれジョエルに馬鹿にされる

555 :仕様書無しさん:2016/10/02(日) 11:18:34.10
>>553
複雑なクエリがどうしても必要なら別に良いんだよ。
でも他の方法があるのに拘る必要は全く無いよね。

556 :仕様書無しさん:2016/10/02(日) 11:19:03.81
実行計画って何さ?

557 :仕様書無しさん:2016/10/02(日) 11:21:10.39
>>554
ええ、それが小難しいって、どんな低スキル・・・
基本中の基本なんだけどさ

558 :仕様書無しさん:2016/10/02(日) 11:22:07.39
>>557
データと表現を分けて考えろってんだろ?
おまえはウンコ食ってろ。

559 :仕様書無しさん:2016/10/02(日) 11:22:50.92
>>555
同意
なんでもかんでもSQLは駄目だな

560 :仕様書無しさん:2016/10/02(日) 11:23:23.15
そのほうが汎用性のある作りになるんだよーって
そんなの判ってるわ。
でも小手先のクエリにそこまで求めてないの。

561 :仕様書無しさん:2016/10/02(日) 11:24:46.11
その場しのぎの開発、いつも乙かれさまです〜

562 :仕様書無しさん:2016/10/02(日) 11:25:21.20
そして、永続化の手段がDBである必要もない

563 :仕様書無しさん:2016/10/02(日) 11:26:14.62
お前らが言ってる「なんでもSQLで〜」って>>552みたいなレベルの事なのか?

564 :仕様書無しさん:2016/10/02(日) 11:26:40.86
日付フォーマットがどうでも良いと感じる理由は
それがクエリの一番外側のSELECTで行われるからだ。
クエリで書こうがフェッチ後にプログラムで加工しようが、そこまで労力が変わらん。
気持ち悪いという意見はあると思う。

565 :仕様書無しさん:2016/10/02(日) 11:28:06.06
>>563
良い例が思いつかない

566 :仕様書無しさん:2016/10/02(日) 11:31:19.79
まあビューで適当な表現で見せれば、それが一番良いかもね。

567 :仕様書無しさん:2016/10/02(日) 11:34:53.01
この話題には問題の大小があって、一緒くたに話すと齟齬が生じる

568 :仕様書無しさん:2016/10/02(日) 11:35:15.81
>>552みたいなのは素直に中途半端なSQLと言うべき
なんでも〜とか言うとさも複雑怪奇なデータ加工をしているように聞こえる

569 :仕様書無しさん:2016/10/02(日) 11:38:46.40
文字列置換やIF、CASEの分岐みたいなのは
基本的にSQLでやるべきではない

570 :仕様書無しさん:2016/10/02(日) 11:42:22.60
何百万レコードとかの大規模なデータの複雑な集計は、
多少無理してでも、全てSQLでやらんと要件満たせない時あるよねー
まあ極端な例だけど

571 :仕様書無しさん:2016/10/02(日) 11:44:35.35
>>569
それもちょっと違う
プレゼンテーション層の表現の加工はプログラム側でやった方が良い場合が多いけど
計算途中の値の写像はSQLに閉じ込められるのならその方が良い

572 :仕様書無しさん:2016/10/02(日) 11:46:15.83
>>571
いや、"基本的"って書いてあるんだから、まさにそれが例外だと思う

573 :仕様書無しさん:2016/10/02(日) 11:46:44.95
ちなみに、>>572>>569じゃないですよ

574 :仕様書無しさん:2016/10/02(日) 11:48:06.28
>>562
KVMの流行はもう終わりましたよ

575 :仕様書無しさん:2016/10/02(日) 11:48:55.32
KVSやった

576 :仕様書無しさん:2016/10/02(日) 11:52:03.45
う〜〜MONGO♪

577 :仕様書無しさん:2016/10/02(日) 11:55:39.37
mongoは再起動しないとハングするしテーブル壊れるし最悪だった

578 :仕様書無しさん:2016/10/02(日) 12:15:00.65
RDBMSでは扱いにくいデータっていうのは確かにあるんだが、
それは例外的な場合で、エクセルが何にでも使われるように
表形式のデータ=RDBMSで扱いやすいデータが多いし
そう扱えるようにしたくなるものなんだよね。

579 :仕様書無しさん:2016/10/02(日) 14:28:22.04
設計するときってどう進めて行くの?

俺からするとやたら難しそうなことを難しい手順で行おうとしてるんだけど、その人はできるっていう(ベテランのおじいちゃん)。

だけど、今は人に理解できるレベルでなく、それを否定をするか、思考をコピーした上で、改善を提案するか、どうすればいいか分からん。

580 :仕様書無しさん:2016/10/02(日) 14:43:50.16
相手の方がベテランなら、判断は相手にさせろよ
こっち(若手)が相手の実装を理解する必要は無い
こちらから提案する簡単な実装が理解できないなら、そりゃベテランじゃなくて只のジジイだ

581 :仕様書無しさん:2016/10/02(日) 17:40:32.40
>>579
だーんと行って後で細かいところを拾おうとしているのか、
こまこま回り道しながら行くけど一回で終わるのか、の違いじゃないの?

スキルがないやつが後者をやろうとすると迷子になって大変なことになるけど、
本筋をきちんと追える人なら大丈夫だよ。
そのおじいちゃんが、きちんと追える人なのかはわからんけど。

582 :仕様書無しさん:2016/10/02(日) 18:12:21.09
(この長嶋茂雄的な言語感覚、さてはこいつ天才か…)

583 :仕様書無しさん:2016/10/02(日) 18:24:34.61
>>581
帳票出力するアプリなんだけど、帳票そのものとデータを一緒に取り込もうとしてる。
データ(csv)だけ渡せばいいと思うのに。

ユーザーはデータ形式だとよく分からないっていうのは、ごもっともだと思うけど、入力も出力も一緒にできるとかありえるの。

テストケースが爆発するとしか思えないのだ。

584 :仕様書無しさん:2016/10/02(日) 20:10:13.66
>>583
そんな説明でじじいが妥当かお前が妥当かなんて判断できない
だからじじいかチームメンバーに直接相談しろハゲ

585 :仕様書無しさん:2016/10/02(日) 20:23:44.05
>>583
疑問を持つ以前に、君が何を言ってるのかさっぱりわからん

586 :仕様書無しさん:2016/10/02(日) 22:27:35.56
>>582
(ばれた?)

>>583
オブジェクト指向のクラスとかも同じ説明されるよね?
界面さえうまくできれば、csvなんていう解釈の幅が広い形式を
使わなくてもよい分、テストケースも最小限にできるかもしれない。

587 :仕様書無しさん:2016/10/02(日) 22:31:18.71
SQLっていうのは速ければいい
速ければ速いほどいい
プログラマでSQLを読めるやつは少ないのであまりコードレビューでも突っ込まれない
自由に好きに書けるわけだ

おまえらの現場だってデータベーススペシャリストは1人いればいいほうだろ?
大抵はSQLでデータ引っ張ってきて、言語側でちょっとした加工するしか出来ない低スキルばかりだ
MVC分離や「SQLを保守する」みたいな理想を掲げているところならともかく
大抵はMVCは分離しないし、SQLは使い捨てだ

そもそもプログラマにサーバ設定はおろかDB設定すら変更させない現場ばかり
「SQLの変更だけで対応して欲しい」っていうのは既存設定依存のサーカスをやらせるようなもんだ
定番の書き方すら通用しない生産性や速度を犠牲とした誰もしないやり方

プログラムより速度に影響する可能性が高いんだから
おまえらもうちょっとデータベースに興味持とうぜ

588 :仕様書無しさん:2016/10/02(日) 22:34:11.12
ちなみにCSV出力なんてSQL一発だからな
おまえらはDBからの戻り値を何も加工せずにファイルに出力するだけでいい

>>579
まず日本語の勉強からだ!

589 :仕様書無しさん:2016/10/02(日) 22:48:17.59
>>583が何を言っているのか頑張って想像してみたけど分からない

590 :仕様書無しさん:2016/10/02(日) 22:54:16.81
>>583
作成しようとしているのは帳票アプリ
連携部分で帳票そのものを渡している(CSVで渡せばいいのに・・・)

エンドユーザーはCSVだとわかりづらいかもしれないが、帳票のまま渡すなんてぶっちゃけありえない
テスト面倒だしな

こういうこと?

591 :仕様書無しさん:2016/10/02(日) 23:02:42.17
>>587
> プログラマでSQLを読めるやつは少ない
> おまえらの現場だってデータベーススペシャリストは1人いればいいほう

20年ほど業務、Web系で職業マやってるけど、そんなスペシャリストみたことないし、そんな現場も1度もないな
たぶん、俺と住んでる世界が違う
DBシステムに携わるプログラマならSQLは必須じゃないの?

592 :仕様書無しさん:2016/10/02(日) 23:05:55.70
資格持ってるだけの奴だったら一人くらいはいるんじゃね?w

593 :仕様書無しさん:2016/10/02(日) 23:08:10.98
と書いてみたけど、年齢が下がるほど、SQLはよく分からないけど・・・
という人が増える感じはする
ORMの弊害かな

594 :仕様書無しさん:2016/10/03(月) 00:29:09.27
>>593
想像で語るなよ。

ORMはあくまでマッピングしてくれるだけなんだから
SQLを直接触れなきゃ使えないってーの。

595 :仕様書無しさん:2016/10/03(月) 00:30:20.12
まあ年齢が下がるほど、技術力は低くなるのは当たり前だから
そりゃ年齢が低くなれば、プログラム言語(SQLを含む)の知識は減るだろうさ

596 :仕様書無しさん:2016/10/03(月) 00:47:18.07
>>591
マシンスペックがあがったおかげで適当なSQLでも速度的に問題になることは少ないし
プログラム側でごまかすことができるから
SQLのスキルがいつまでたってもあがらない

データベースから全件とってきてVBで結合・検索処理したって発覚するまで数年かかるからな

597 :仕様書無しさん:2016/10/03(月) 00:48:27.69
> データベースから全件とってきてVBで結合・検索処理したって発覚するまで数年かかるからな

なんでコードレビューでそれが見つからないんだ?

598 :仕様書無しさん:2016/10/03(月) 01:02:18.83
流れから読み取ると、
教える側が十分に理解してないから若手を育てられない、というのが現状か

599 :仕様書無しさん:2016/10/03(月) 01:03:12.46
>>597
VB側のコードはまともだったからなw
マイグレーション絡みのどさくさで紛れ込んだってのもあるし、当初は速度的に問題がなかった
件数増えてきて速度が遅いとクレームがついたから、ヘルプに入ったらこの有様だったってこった

みんなSQLが苦手だから突っ込みたくなかったんだろうな
横に長いテーブルを複数結合してるだけでもやる気がなくなるのに
複数のデータベースを跨いで、条件分岐付の計算後の値で検索させるなど面倒といえば面倒

まぁ、こういうレベルの話をしたいわけじゃないが、極端な例でしかもありがちだから挙げてみた

600 :仕様書無しさん:2016/10/03(月) 01:20:44.52
>>599
VB側のコードがまともじゃなかったって話だろう?
全件とってくるなんてコードレビューで見つけるべきものの一つじゃんか。

> 横に長いテーブルを複数結合してるだけでもやる気がなくなるのに
> 複数のデータベースを跨いで、条件分岐付の計算後の値で検索させるなど面倒といえば面倒

それSQL以前にRDBMSの設計に問題あるだろ?
まさか新人が設計したのか? にしてもコードレビューはあるはずだし。

601 :仕様書無しさん:2016/10/03(月) 07:30:07.34
>>591
数万件程度の小さなデータ量ならともかく
Web系でも巨大なデータを扱う所は、なまくらのSQLだと
偶然良い感じに動くか、いずれ熟練者のチューニングが必要になる

602 :仕様書無しさん:2016/10/03(月) 19:20:29.16
>>594
お前が言ってるのはORマッパーじゃなくてObject/SQLマッパーねw

603 :仕様書無しさん:2016/10/03(月) 19:55:47.00
題材を決めてコード書いて比べないのは何故?

604 :仕様書無しさん:2016/10/03(月) 21:45:52.06
>>602
> Object/SQLマッパー

そんなもの存在しないよ。

605 :仕様書無しさん:2016/10/03(月) 22:30:35.46
>>594
> ORMはあくまでマッピングしてくれるだけなんだから

この言い方、O/Rマッパーが、SQLの結果をオブジェクトにマッピングするものだと思ってる感がありありw

606 :仕様書無しさん:2016/10/03(月) 23:38:51.84
>>603
プログラミングのセンスっつうのは、そういうのとは、ちょっと違うんじゃよ

607 :仕様書無しさん:2016/10/04(火) 00:13:55.92
柔軟に対応できる設定っていうのは
一見するとつまんない設計なんだよな

608 :仕様書無しさん:2016/10/04(火) 00:14:57.55
>>606
そういうのに乗り気かどうかは、関係あるよね

609 :仕様書無しさん:2016/10/04(火) 00:33:03.27
>>605
> この言い方、O/Rマッパーが、SQLの結果をオブジェクトにマッピングするものだと思ってる感がありありw

それ誰が言ってるの?
お前以外誰もそんなこと言ってないけど?

610 :仕様書無しさん:2016/10/04(火) 00:36:14.96
>>608
いんや、俺は興味ないね
アルゴリズムを競う時代はもう終わってる

まあ、新人とか未経験者は、そういうのに乗って頑張って欲しいとは思うが
ここのスレでそれをやるのは、なんか違う

611 :仕様書無しさん:2016/10/04(火) 00:46:10.40
しかし、スタイルで揉めつつも実を語らない
見ているだけの野球ファンが
選手をあーだこーだとエラそーに言ってるだけ

612 :仕様書無しさん:2016/10/04(火) 01:08:15.07
わかってねーな
揉めてるのはセンスない奴らだけだよ
おまえが実を読めてないんじゃん

613 :仕様書無しさん:2016/10/04(火) 01:36:03.22
センスのある人って問題にぶち当たらないんだよな

614 :仕様書無しさん:2016/10/04(火) 01:44:03.50
ここにセンスのあるヤツがいるのだろうか

615 :仕様書無しさん:2016/10/04(火) 01:52:43.37
教えたことを素直に飲み込んでくれるなら
むしろ変なセンスは無い方が良い場合も

616 :仕様書無しさん:2016/10/04(火) 06:17:27.87
このスレもおじいちゃんばっかじゃねーかw

617 :仕様書無しさん:2016/10/04(火) 06:18:31.62
なんでセンスがある奴が素直に飲み込めないと思ったのかが疑問
センスがない奴はスキルも低いから素直に動けない
適当に食材や調味料を放り込んで、糞まずい料理を作る奴いるじゃん
それと同じよ

618 :仕様書無しさん:2016/10/04(火) 06:43:17.22
言葉を覚えたての赤ん坊じゃないけど
あまり意味のない一工夫をしたがるけど
そこで必ずと言って良いほど不具合を出すという

逆に、センスがある奴は不具合も少ない

619 :仕様書無しさん:2016/10/04(火) 13:12:35.42
【犯罪者追放のお願い】
大金・知財・健康・家族を失ってからでは、取り返しがつきません。
犯罪者に従うのも犯罪です。犯罪行為を最寄りの警察署に通報して下さい。
※通報者のプライバシーは保護されます。

刑法62条 幇助罪
犯罪行為を幇助した

刑法第246条 詐欺罪
虚偽による契約を交付された

刑法第223条 強要罪
作業の期日等を強要された

刑法第234条 威力業務妨害罪
職権等の威力によって業務を妨害された

職業安定法第44条 労働者供給事業の禁止
業務の時間・場所・方法等を指示された

警察官の対応に問題があった場合は、 監察局、
各都道府県の警察本部監察官室、 公安委員会に苦情申出して下さい。

http://www.gov-online.go.jp/useful/article/201111/3.html

620 :615:2016/10/05(水) 01:39:25.64
一見、センスがあるように見える奴は要注意
と、言っておるのじゃよ

皆が云うとおり、本当にセンスがある(センスが良い?)なら問題ないのである

621 :仕様書無しさん:2016/10/05(水) 08:32:09.91
AがBに物を教えるとき、うまく伝わらないのはどちらかのセンス(感覚)がおかしいから。
問題なのは、どちらも自分のセンス(感覚)が良いと信じて疑わないことだろう。

622 :仕様書無しさん:2016/10/05(水) 12:28:41.01
ん?つまりどちらもセンスがおかしくない時は
BがAに物を教えるときうまく伝わらないのか?

623 :仕様書無しさん:2016/10/05(水) 12:59:14.36
【偽装請負・多重派遣の横奪損失】

巨額の料金を奪われてんだぞ!
横取り犯人を訴えないのかよ!

裁判で横取り料金を取り戻せ!
盗難被害額分の作業を減らせ!

システム開発報酬盗難被害の多発事件例

加害者
発注者 支払 140万円/人月 1億円/人月の大儲け

被害者
1次受注者 報酬 120万円/人月 20万円/人月の盗難被害
2次受注者 報酬 80万円/人月 60万円/人月の盗難被害
3次受注者 報酬 60万円/人月 80万円/人月の盗難被害

624 :仕様書無しさん:2016/10/05(水) 13:13:34.81
>>622
そのケースの伝わるか伝わらないかは、元々記述されてないように見受けられる。

625 :仕様書無しさん:2016/10/05(水) 18:50:54.40
ん?つまりどちらもセンスがおかしくない時は不定という事か?
てことはそもそも伝わるか伝わらないかにセンスは関係ない?

626 :仕様書無しさん:2016/10/05(水) 20:59:04.87
そんなことより野球しようぜ

627 :仕様書無しさん:2016/10/05(水) 21:12:35.15
センスのない奴がセンスある人をディスりたいだけだから

628 :仕様書無しさん:2016/10/05(水) 21:14:17.51
>>621
センスがある人はイメージで伝えるのがうまい
センスのない人は文章じゃないと理解できない

629 :仕様書無しさん:2016/10/05(水) 21:32:44.55
>>628
だから図や表が必要なんだろうが。

630 :仕様書無しさん:2016/10/05(水) 21:34:19.26
ほとんどの人間はプログラムセンスなんてないよ。

プログラムセンスがあったらプログラマだけやっているはずがない。

631 :仕様書無しさん:2016/10/05(水) 21:41:33.03
ほとんどの人間がプログラマじゃないのはプログラムセンスがあるからなの?

632 :仕様書無しさん:2016/10/05(水) 23:24:32.65
>>629
図表というか、文字を含まないイメージ

633 :仕様書無しさん:2016/10/06(木) 00:58:09.82
図や絵や文字のどれを使うかは問題じゃない
見た人が何秒でわかるかが大事

634 :仕様書無しさん:2016/10/06(木) 11:10:58.80
無能実態派遣残業して時間報酬相場下げるな!
【知的財産と契約料金の搾取促進者ばかり】
[SI生涯損害助長SEを追放すべき]
偽装請負従犯SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの迷惑
無償プログラム提供
事前面接
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
時間外労働違反
低予備工数見積
残業見積
無料追加
学習不足
裁判苦手
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
低収入低技術
非婚離婚
鬱病早死

635 :仕様書無しさん:2016/10/06(木) 12:40:18.91
>>633
これだよね
いかに他人が理解しやすいものを作るか

636 :仕様書無しさん:2016/10/06(木) 15:40:27.15
理解しやすいかどうかは社会性センス
本当に優れた物は極めて理解しにくい

637 :仕様書無しさん:2016/10/07(金) 00:43:40.99
トップレベルの競技プログラマーはセンスすごい

638 :仕様書無しさん:2016/10/07(金) 00:46:08.73
つまり俺の性癖は極めて優れているのか

639 :仕様書無しさん:2016/10/07(金) 02:03:36.69
・穴をみつけて侵入する
・臭いところを嗅ぎつけるのが得意
・上級者になるほど他人にやらせて自分は見るだけ

どこの世界でもセンスのある人は共通らしい

640 :仕様書無しさん:2016/10/07(金) 06:35:01.66
最後はないな

641 :仕様書無しさん:2016/10/07(金) 06:45:59.12
サッカー中継を見て「何やってんだ下手糞死ねや!」と騒いでる
サッカード素人の視聴者全員がセンスありになってしまうわ

642 :仕様書無しさん:2016/10/07(金) 09:36:38.97
> ・上級者になるほど他人にやらせて自分は見るだけ

それ違うだろw

その理屈だと経営者=上級者
監督=上級者ってことになるぞ。

643 :仕様書無しさん:2016/10/07(金) 11:35:07.88
低報酬ITドカタへ

無能残業・低料金化・健康障害・対人障害のせいだろ!
異常者ばかりで迷惑だから技術評価は報酬金額で表せ!

SEの報酬不足レベルを立証
正社員の人手不足業界ランキング
1位:情報サービス 59.3%
2位:建設 54.6%
3位:医薬品・日用雑貨品小売 53.6%
4位:放送 53.3%
5位:旅館・ホテル 52.8%
6位:人材派遣 52.6%
7位:運輸・倉庫 50.0%
8位:金融 49.1%
9位:専門サービス 48.3%
10位:メンテナンス・警備 48.1%

人手不足業界は独身率も高い
http://raorsh.com/hitode

644 :仕様書無しさん:2016/10/08(土) 00:53:55.62
>>642
社会的地位の話じゃないの?

645 :仕様書無しさん:2016/10/08(土) 02:35:50.85
見てるだけの経営者にプログラムセンスは不要だろ

646 :仕様書無しさん:2016/10/09(日) 16:30:09.78
>>645
経営者層にわかる人がいないとロクな会社にならない

647 :仕様書無しさん:2016/10/09(日) 18:23:55.20
IBMって経営者騙すの得意だよね

648 :仕様書無しさん:2016/10/09(日) 18:31:46.54
>>647
いまの日本IBMは自分たちではシステム作れないからなw

649 :仕様書無しさん:2016/10/09(日) 18:37:30.30
スルガ銀行の事か・・・

650 :仕様書無しさん:2016/10/10(月) 10:12:31.01
技術者の結婚問題

技術ない方が収入と寿命が高いって有り得ないだろ!
相場が下がって迷惑だから収入上げるか技術下げろ!

放送・商社・銀行・公務 > 製造・化学・通信・情報

2014年度有価証券報告書より
伊藤忠商事 1,395万円(41.5歳)
三菱商事  1,376万円(42.6歳)
三井物産  1,361万円(42.4歳)
丸紅    1,306万円(41.5歳)
住友商事  1,301万円(42.8歳)

http://m.finance.yahoo.co.jp/stock/fundamental?code=4676.T

651 :仕様書無しさん:2016/10/11(火) 08:44:01.11
【主な偽装請負従犯結婚障害者の作業】
[文系多数の貧困非婚スキル]
コマンド
スクリプト
データ > ロジック
簡単ロジック
大量データ
SE適性不要
IT資格不要
大卒資格不要
文科系対象
体育系対象
商業系業種
業務系処理

[技術不要の貧困非婚ソフト]
ノンプログラミングツール
フレームワーク
Web
COBOL
VB
.net
Java
DB
ERP
SAP

652 :仕様書無しさん:2016/10/12(水) 09:04:53.32
SEの不健康と低知能の時間外労働違反対策

訴訟や非婚が増えて迷惑だから残業は止めろ!
優秀なSEや共働きに迷惑だから残業は止めろ!

時間外労働違反となる
無能技術者が増加する
多数が嫌う職種である
将来削減の業界である
共働き結婚妨害である
契約に作業期限はない
契約終了が早期化する
定年退職が早期化する
健康障害をもたらす
対人障害をもたらす
生産効率が低下する
生産評価が低下する
能力評価が低下する
時間報酬が低下する
情報技術が低下する
生涯収入が低下する
学習時間が減少する
副業時間が減少する
訴訟が増加する
失業が増加する
貧困が増加する
独身が増加する
早死が増加する

653 :仕様書無しさん:2016/10/13(木) 12:27:08.04
勘違いITドカタへ

Web/Java/COBOL/DB
データ処理要員等の
委任契約の事務員は
請負契約の技術者と名乗るな!

主婦向けレベル作業だろ
恥にも程があるあるだろ
実態派遣のくせに残業するな!

準委任契約は事務契約
(準委任)第656条 この節の規定は、法律行為でない事務の委託について準用する。

654 :仕様書無しさん:2016/10/14(金) 19:09:10.89
年収1,000万円以下の低レベルSEへ

SEの低生涯収入と短勤続年数の貧困対策考えろ!
報酬下がって迷惑だから交渉するか作業減らせ!
生産下がって迷惑だから技術は報酬で評価しろ!

[推定平均生涯収入]
100万/月 3億5,000万円以上(大卒サラリーマン上位レベル)
90万/月 3億円以上(大卒サラリーマン平均レベル)
80万/月 2億5,000万円以上(大卒サラリーマン下位レベル・高卒サラリーマン上位レベル)
70万/月 2億円以上(高卒サラリーマン平均レベル)
60万/月 1億5,000万円以上(高卒サラリーマン下位レベル)
50万/月 1億円以上(フリーターレベル)
40万/月 5,000万円以上(パートレベル)

655 :仕様書無しさん:2016/10/17(月) 15:21:50.05
アメリカのSEは1,000万円以上だけど
日本のSEは1,000万円以下の低収入!

【アメリカ】
スーパープログラマ
時給10万円だったり、ストックオプションで数億〜数十億円稼ぎだす
Javaフレームワーク
〜3600万円
PHP
〜2400万円
COBOL
〜1700万円
技術サポート
〜1200万円

年収中央値:1175万円(アメリカ労働統計局調査、サンプルは111万人)
70歳でも仕事があり、年収は下がらない
数年単位で転職する(一つの会社に長くいるのは危険)
管理系の職種は雇用が不安定で、報酬も高くない

【日本】
平均年収:430万円(情報処理推進機構調査)

Web/ゲーム業界(昔ほど報酬は高くない)以外は人月単位のため、報酬には上限あり

年功賃金を採用する企業では20代後半までの給料は一部の例外を除き低い
間接雇用が基本(大手のSIerでも客先常駐派遣が少なくない)
40歳以降になるとリストラ候補となり、一旦リストラされると低賃金職か、長期間無職となる
大企業の場合は管理職トラックに進むためコーディングはしなくなり、
プログラミング経験が昔あっても35歳以降の転職は難しい
転職回数が3回超えるだけで大手には書類で落とす。

656 :仕様書無しさん:2016/10/18(火) 10:17:08.18
SEの経済損失

SI業界は善悪損益が世間と正反対!
プログラム生産するほど貧困非婚!

プログラムの巨額利益を客先に提供
プログラムの巨額報酬を人売に提供
会社員なのに短勤続年数
人手不足なのに無職意識
人手不足なのに低収入
高生産なのに低収入
高利益なのに低収入
高需要なのに低収入
勤勉なのに低収入
高稼働残業して非婚
高稼働残業して離婚
多重派遣なのに稼働
偽装請負なのに稼働

ピンハネ商流
http://freelance-programmer.com/shouryu

657 :仕様書無しさん:2016/10/26(水) 08:06:08.74
【犯罪者追放のお願い】

犯罪者個人に対して告訴状を偽装請負・偽装出向・多重派遣の被害者が作成(刑事告訴は無料) or 司法書士が代筆(料金は5万円ぐらい)

告訴状を【検察の直告班】に郵便局の内容証明付で送付(疎明資料・証拠にはICレコーダー、スマホによる録音が適しています)

審査 → 不受理 → 告訴状再提出または刑法 第193条で訴えを起こす

受理 → 告訴事実を認め示談交渉(↓) →示談成立  →法廷相場50〜100万円の示談金 ※示談拒否が良い
↓                ↓
事案化 ←←←←←← 示談不成立(↓) →示談外交渉 →犯罪者の年収半額×最大懲役年数の和解金支払い※推奨
↓                ↓
↓               起訴  →公判  →罰金刑=前科(起訴事実を認めてるため)→追討ち民事訴訟
↓                    
審査 → 起訴(強制捜査・留置場)→ 公判 → 懲役刑などの厳罰(反省が認められないため)→追討ち民事訴訟

不起訴、起訴猶予

検察審査会法第30条(検察審査会へ申し立て)→ 起訴 → 起訴後は同上
刑法 第193条(公務員職権濫用)で検察事務官を刑事告訴 → 同上

◎告訴→告訴受理→示談交渉→厳罰を求め示談不成立→示談外交渉→和解金支払い・和解契約(公正証書・即決和解で秘密保持契約)
◎偽装請負・出向・違法派遣事件では派遣・出向先両方の代表者、役員、現場責任者に告訴できます。
前科がついた犯罪者が法人の代表であれば公的な入札からの排除、取引先や顧客との契約解除など社会的制裁・批判に晒されることから辞職または解任が妥当、役員・社員であれば懲戒を想定。
◎事業者内部の加害関係者による刑事告発(刑事訴訟法239条1項)も可能です。
加害者本人、管理間接部門の社員が刑事告発に踏み切る場合も和解金による解決が妥当です。

注意:告訴が受理されない理由
●3年間(※)の時効が過ぎたもの ※違法派遣
●同一事実について過去に告訴取消しがあったもの
●関連する民事訴訟を有利に導く目的の場合
●証拠が希薄なもの ※被害者が契約時に違法派遣・偽装請負・多重派遣と知っていても刑事告訴は有効です。

658 :仕様書無しさん:2016/10/27(木) 09:11:13.46
【犯罪者追放のお願い】

告訴の趣旨
 被告訴人は、以下に該当すると考えるので、被告訴人の厳重な処罰を求めるため告訴します。
●職務経歴書を提示した事前面接を実施・偽装請・偽装出向
 労働者派遣法第26条(契約の内容等)に違反
職業安定法第44条(労働者供給)に違反
●多重派遣・多重出向
 労働基準法第6条(中間搾取の禁止)に違反

疎明資料
■事前面接日時・場所・出席者・資料のコピー、音声記録
 就業場所・就業期間・就業時間
 指揮命令
  指示を誰が行っているかの記録、音声記録
 仕事で使う道具や、資材の負担(所有)のあり方
  業務で使用しているパソコン・備品などの所有者
■契約書
 請負・雇用契約書、出向指示など書面のコピー

刑事告訴ガイダンス
★和解金の相場は犯罪者の去年の年収の半額です。社長や役員で数千万〜1億円、管理職で500〜1000万円、営業個人については200〜500万円程度。
★痴漢も民事でなく刑事事案ですが、裁判所が和解金を被害者に支払わせて解決するのが絶対的過半数です。和解で解決しない事案、つまり公訴までいって判例となる事例を探すほうが難しいことでしょう。
★録音は一方の当事者が取る限り合法です。※加害者に録音の同意を求める必要はありません。
★告訴状を検察に提出しても受理されなければ加害者側には知られることはありません。不受理の場合は何事も起きてないように粛々と振る舞ってください。
★告訴を取り下げるとき検察に提出した資料は全て返却されます。また検察があなたが提出した証拠をあなたの許可なく裁判の証拠として使用はできません。告訴を取り下げたのちの録音資料には当事者の立場が失われるため証拠能力はありません。
★和解時に告訴した事実は秘匿事項となります。犯罪者が秘密保持契約に違反した場合の損害賠償金は「即決和解」か「公正証書」で最低5000万円〜にしましょう。支払いを拒否すれば強制執行手続きを地方裁判所に上訴(裁判不要)してください。
★派遣会社や事業会社が同業者に情報をリークしたなら競合他社に弱みを握られます。余程信用のおける相手でなければリークはできないでしょう。漏らした方の口が軽ければ事実は分かります。また密告してくれた事業者には損害賠償金の3割を謝礼金として渡してください。

659 :仕様書無しさん:2016/10/29(土) 08:53:11.69
この頭のおかしい荒らしなんとかならんのかな
ワッチョイとIP付きでスレ建て直して良いか?

660 :仕様書無しさん:2016/10/29(土) 10:23:42.41
まあ頭おかしくない荒らしなんていないけどね

661 :仕様書無しさん:2016/10/29(土) 10:37:21.97
>>659
>>660
主な受注SEの結婚障害

無能残業して共働き妨害するな!
巨額搾取させて生活妨害するな!

・異性にモテない
・コミュニケーションが苦手
・ファッションセンスがない
・コンピューターが趣味
・プログラムの巨額利益を客先に提供
・プログラムの巨額報酬を人売に提供
・会社員なのに短勤続年数
・人手不足なのに無職意識
・人手不足なのに低収入
・高生産なのに低収入
・高利益なのに低収入
・高需要なのに低収入
・勤勉なのに低収入
・多重派遣なのに稼働
・偽装請負なのに稼働
・運動不足で不健康
・高稼働で不健康
・高稼働で家事困難
・低収入で生活困難

【SE】結婚障害【PG】
片働き共働き両方とも結婚困難
http://hanabi.2ch.net/test/read.cgi/infosys/1477540734/

662 :仕様書無しさん:2016/10/29(土) 10:38:19.00
>>659
>>660
SEの巨額経済損失

巨額経済損失で結婚相手に大負担!
SI業界は善悪損益が世間と正反対!
プログラム生産するほど貧困非婚!

プログラムの巨額利益を客先に提供
プログラムの巨額報酬を人売に提供
会社員なのに短勤続年数
人手不足なのに無職意識
人手不足なのに低収入
高生産なのに低収入
高利益なのに低収入
高需要なのに低収入
勤勉なのに低収入
運動不足で不健康
高稼働残業で不健康
高稼働残業して非婚
高稼働残業して離婚
多重派遣なのに稼働
偽装請負なのに稼働

ピンハネ商流
http://freelance-programmer.com/shouryu

663 :仕様書無しさん:2016/10/31(月) 10:50:10.79
【犯罪者追放のお願い】
大金・知財・健康・家族を失ってからでは、取り返しがつきません。
犯罪者に従うのも犯罪です。犯罪行為を最寄りの警察署に通報して下さい。
※通報者のプライバシーは保護されます。

刑法62条 幇助罪
犯罪行為を幇助した

刑法第246条 詐欺罪
虚偽による契約を交付された

刑法第223条 強要罪
作業の期日等を強要された

刑法第234条 威力業務妨害罪
職権等の威力によって業務を妨害された

職業安定法第44条 労働者供給事業の禁止
業務の時間・場所・方法等を指示された

警察官の対応に問題があった場合は、 監察局、
各都道府県の警察本部監察官室、 公安委員会に苦情申出して下さい。

http://www.gov-online.go.jp/useful/article/201111/3.html

664 :仕様書無しさん:2016/11/01(火) 10:42:34.21
【偽装請負・多重派遣の横奪被害】

巨額の料金を奪われてんだぞ!
横取り犯人を訴えないのかよ!

裁判で横取り料金を取り戻せ!
盗難被害額分の作業を減らせ!

システム開発報酬盗難被害の事件例

加害者
発注者 支払 140万円/人月 1億円/人月の大儲け

被害者
1次受注者 報酬 120万円/人月 20万円/人月の盗難被害
2次受注者 報酬 80万円/人月 60万円/人月の盗難被害
3次受注者 報酬 60万円/人月 80万円/人月の盗難被害

665 :仕様書無しさん:2016/11/02(水) 10:11:29.81
無能実態派遣残業して時間報酬相場下げるな!
【知的財産と契約料金の搾取促進者ばかり】
[SI生涯損害助長SEを追放すべき]
偽装請負従犯SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの損害
無償プログラム提供
事前面接
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
時間外労働違反
低予備工数見積
残業見積
無料追加
学習不足
裁判苦手
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
低収入低技術
非婚離婚
鬱病早死

666 :仕様書無しさん:2016/11/04(金) 17:48:16.55
【主な偽装請負従犯結婚障害者の作業】
[文系多数の使い捨て貧困非婚スキル]
コマンド
スクリプト
データ > ロジック
簡単ロジック
大量データ
SE適性不要
IT資格不要
大卒資格不要
文科系対象
体育系対象
商業系業種
業務系処理

[技術不要の使い捨て貧困非婚ソフト]
ノンプログラミングツール
フレームワーク
Web
COBOL
VB
.net
Java
DB
ERP
SAP

667 :仕様書無しさん:2017/01/06(金) 16:47:33.76
コンパイラー<例外キャッチしろボケが!
わい<うぜぇな、これでええやろ
catch(Exception e) {
throw new RuntimeException(e);
}
コンパイラー<^^

668 :仕様書無しさん:2017/01/06(金) 22:34:13.68
try{
}catch(...){}

いかんのか?

669 :仕様書無しさん:2017/01/17(火) 18:10:49.73
>>668
負けたわ

670 :仕様書無しさん:2017/02/24(金) 23:39:44.05
握りつぶせ!エラー

671 :仕様書無しさん:2017/02/24(金) 23:42:19.60
それはイカンな
デバッグログに吐いて

672 :仕様書無しさん:2017/02/27(月) 19:14:17.52
>>1
>センスある人・・・例外をうまく使ってシンプルなコードを書くことができる

こういうコードのこと?
foo(Object a,Object b) {
try {
a.getVlue();
} catch(NullPointerException e) {
b.getValue();
}
}

673 :仕様書無しさん:2017/02/27(月) 19:28:23.19
仕様による

引数のobjectの型そのものを定義して
nullか入らないようにも出来るし

674 :仕様書無しさん:2017/02/28(火) 09:35:51.57
>>672
Currencyを引数に何か計算する関数で…
普通の人:システムのサポート外、その関数の役割外のCurrencyにはさっさと例外を投げる。
バカ:世界の通貨を全部勝手に実装する。
アホ:対応外の通貨には0とかのてきとーな値を勝手に返す。

みたいな話かなと勝手に思ってた

675 :仕様書無しさん:2017/02/28(火) 09:41:38.57
そーいうのはenumでハジいてけろ

676 :仕様書無しさん:2017/02/28(火) 09:51:08.14
その普通の実装をすると貶されるアホの世界は実在する

677 :仕様書無しさん:2017/02/28(火) 19:22:31.84
普通の実装というものが存在すると思ってるアホはよく見かける…あ、居たw

678 :仕様書無しさん:2017/03/02(木) 19:39:56.20
>>672
コーディング規約で禁止になりそうな書き方じゃん
うまくはないね。個性的なだけで。
Appleはそういうの好きだろうけど。
CDをゴミ箱に捨てると蓋が開くとか
そういうのとおんなじセンス。

679 :仕様書無しさん:2017/03/03(金) 09:31:50.70
out of baseは、どんなに長くなっても一行に書く。
out of baseは、,の後に絶対にスペースは1つ。
out of baseは、TABはスペース2つ。
out of baseは、()を省略する・・・ってか意地でも書かない。
out of baseは、高速列挙以外認めない。
out of baseは、if文より三項演算子を使う。

680 :仕様書無しさん:2017/03/03(金) 10:17:24.35
センスがある人・・・勉強の情報源がネット
センスがない人・・・勉強の情報源が本

681 :仕様書無しさん:2017/03/03(金) 10:29:13.79
そりゃ関係無いな
逆にネットの情報を鵜呑みにしてる奴の方がセンス無くてたち悪い
コピペプログラマみたいな

682 :仕様書無しさん:2017/03/03(金) 12:23:33.36
自分なりの理想形を頭に描いてる
自分の成果物に疑いを持ち、より良い解決を考えてる

そして空気の淀んだ会社には居着かない

683 :仕様書無しさん:2017/03/03(金) 12:32:13.33
おかしいな起ちは良い方のハズなんだけど…

684 :仕様書無しさん:2017/03/03(金) 14:37:38.81
>>680
お前センスねーな

685 :仕様書無しさん:2017/03/04(土) 20:28:26.33
図星付かれたからって怒らないで(´・ω・`)
机にプログラム本どっさり置いて作業中に見てる奴にまともなプログラム作れる奴なんかいねーよ。
センスある奴はネットで情報探すから本なんか置いてない。作って覚えるんだよ。
君らは寝る前とかでもC++の赤本とか見て勉強してる気になってるんだろ?w

686 :仕様書無しさん:2017/03/04(土) 20:35:26.25
たしかに凄腕のプログラマの周りに参考書が置かれてるのを見たことがない

687 :仕様書無しさん:2017/03/04(土) 20:56:09.79
>>686
すでに生き字引だからなぁ

688 :仕様書無しさん:2017/03/04(土) 21:18:09.77
でかい会社だとネットにつなげないことも多いから
そういう環境ではスマホでちまちま検索するよりも
リファレンス本があった方が便利なんやで

689 :仕様書無しさん:2017/03/04(土) 21:21:20.83
>>685
ネットwwww

690 :仕様書無しさん:2017/03/04(土) 21:29:42.78
>>688
凄腕はネットも本もないところでも仕事ができる
ネット環境があるに越したことはないけどな

691 :仕様書無しさん:2017/03/04(土) 21:37:44.28
>>688
システムの納入先で調整や改造が必要になったら超役に立たねー奴だろうなぁ。
客先やサーバー室で、ネットどころかスマホすら使えない環境で仕事しなきゃいけないことだってあるのに。

692 :仕様書無しさん:2017/03/04(土) 21:48:04.65
本派 vs ネット派

コーダー界を二分する熾烈な争いやねw

693 :仕様書無しさん:2017/03/04(土) 23:28:31.26
本もネットも全く見ないでもすごい人はすごいし、
本を読もうがネットで検索しようがバカはバカ。
相関性はあまりない。

694 :仕様書無しさん:2017/03/05(日) 00:08:09.83
本を読んで基礎を身に着け
ネットで調べ応用を知り
コードを書き覚える
でいい?

695 :仕様書無しさん:2017/03/05(日) 00:42:38.00
>>693
凄い人はネットも本も参考にしない
凄くない人はネットか本が無いと書けない

696 :仕様書無しさん:2017/03/05(日) 00:52:17.52
もらいらのいう本て「プロがこっそり使う禁断の奥義1000の逆引き大全」みたいなやつだろw

697 :仕様書無しさん:2017/03/05(日) 00:53:08.53
もらいらてwww

698 :仕様書無しさん:2017/03/05(日) 00:57:19.60
本を読もうが、ネットを見ようが、結果を出す人が凄い人。
課程はあまり関係ない。

699 :仕様書無しさん:2017/03/05(日) 01:19:54.53
まぁそうなんだけど
世の中には目に見える結果と、それ以外の結果が有るのだよ

700 :仕様書無しさん:2017/03/05(日) 01:37:37.18
センスある奴はマ板とかム板とか来ない
というか2ch自体ほとんど使わない

701 :仕様書無しさん:2017/03/05(日) 07:09:03.47
>>700
分かる
あのtanakhさんも2ch使うのやめたしな

702 :仕様書無しさん:2017/03/05(日) 07:24:04.12
何にしても所詮はただの情報源
そこから自分で考えないヤツはAI以下だな

703 :仕様書無しさん:2017/03/05(日) 08:18:32.21
>>700
2chを使うというのが、2chに来るかどうかではなく
2chを情報源に使うかどうかという意味なら、そうだろうな

704 :仕様書無しさん:2017/03/05(日) 09:53:17.58
本棚いっぱいにプログラム本あって「何でこんなに買ったの?」と聞いたら勉強の為と言う。
「君の作品見せて」って聞いたら何も答えられない。
コード記法やアルゴリズムの薀蓄は超一流。自分で作った制作物”なし”。
これが本が情報源の人間(お前ら)の現実なw

705 :仕様書無しさん:2017/03/05(日) 10:07:52.93
君の作品見せて

706 :仕様書無しさん:2017/03/05(日) 11:04:19.65
> 「君の作品見せて」って聞いたら

githubにあるから見ればいいよ

707 :仕様書無しさん:2017/03/05(日) 11:36:09.07
センスある人は
他人(出来ないヤツ)に興味が無い

708 :仕様書無しさん:2017/03/05(日) 12:03:49.90
>>704
2chで超一流の蘊蓄なんか聞いたことないわw

709 :仕様書無しさん:2017/03/05(日) 13:13:12.67
自分に必要な情報がありゃネットだろうが本だろうが見るだろ
問題は自分にとって何が必要なのかも理解してないのに
ネットとか本見て他人の真似して判った気になってる奴だろな

他人の姿と自分を見比べる事でしか自分を評価できない奴
>>704みたいなのが典型的な例

710 :仕様書無しさん:2017/03/05(日) 14:02:45.33
他人と比較したがる奴の多いこと
>>704とか>>709とか

711 :仕様書無しさん:2017/03/05(日) 14:10:06.65
>>709
お前んち鏡ある?w

712 :仕様書無しさん:2017/03/05(日) 14:26:36.24
他人と比較すること以外でどうやって自分を評価するんだろうな。
自分に正直にとか自分で自分を褒めてあげたいとかいう痛いアレか。

713 :仕様書無しさん:2017/03/05(日) 15:17:00.15
>>712
他人を下げて自分を上げようとするのが不快感を生じさせる
他人を上げつつ自分も上げる技術が必要
コミュ力重要

714 :仕様書無しさん:2017/03/05(日) 15:32:47.49
他人と自分を比較=他人か自分を下げるって発想がもうすでに駄目

715 :仕様書無しさん:2017/03/05(日) 16:06:42.99
>>714
はい下げた

716 :仕様書無しさん:2017/03/05(日) 16:10:39.64
アゲアゲで行こうぜ

717 :仕様書無しさん:2017/03/05(日) 16:23:48.57
アゲサゲで逝こうぜ

718 :仕様書無しさん:2017/03/05(日) 17:07:52.68
禿サゲで行こうぜ

719 :仕様書無しさん:2017/03/05(日) 17:08:48.69
http://asg.to/

720 :仕様書無しさん:2017/03/05(日) 18:50:49.07
結局プログラムなんて自己表現の一つで
他人が何を言おうが自分で納得できるならそれでいい
他人がどうだとか言ってる時点でダメ
もっとストイックに生きるべき

721 :仕様書無しさん:2017/03/05(日) 19:11:35.97
>>720
アマチュアならそうかもな

722 :仕様書無しさん:2017/03/05(日) 19:18:34.80
>>721
言われたものしか書けない奴に
プログラマとして同列に見られたくないわ

723 :仕様書無しさん:2017/03/05(日) 19:23:25.83
出来ないヤツは無視しておけば良いけど
出来る人同士は仲良くしないとダメだよ

724 :仕様書無しさん:2017/03/05(日) 19:27:31.23
出来ないヤツも出来るヤツも基本皆仲が良いけど
自称出来るヤツがいつだってチームに火種を持ちこむw

725 :仕様書無しさん:2017/03/05(日) 19:46:51.44
あゴメンwお前ら皆自称出来るヤツだったなw
俺としたことがとんだ場違いな発言をw
さっきの発言は撤回はしないけど…スマナイと思ってる…ww

726 :仕様書無しさん:2017/03/05(日) 20:16:10.93
>>725
独り出来ない奴ごくろーさん

727 :仕様書無しさん:2017/03/05(日) 21:13:17.57
ぼっちの達人現わるw

728 :仕様書無しさん:2017/03/05(日) 22:03:05.64
キミはトイレでご飯を食べるフレンズだね!

729 :仕様書無しさん:2017/03/06(月) 00:28:08.93
プログラマってこんなんばっか

730 :仕様書無しさん:2017/03/06(月) 08:09:05.50
本派(愛読書ロベールC++本、オライリー本)のイライラが募っているな・・・w

731 :仕様書無しさん:2017/03/08(水) 07:52:46.16
ネット使っても覚えないよ。
どのサイトに何が書いてあるかに詳しくなるだけ。

732 :仕様書無しさん:2017/03/08(水) 08:35:21.71
>>706
初心者です。
公開すると勝手に直されたりとか
鬱陶しいことにならないの?

733 :仕様書無しさん:2017/03/10(金) 22:31:37.94
カップヌードルでシーフードが好きなやつはセンスないな
うちのクラスだと100%当たってる

734 :仕様書無しさん:2017/03/10(金) 22:40:41.28
急に食いたくなった

735 :仕様書無しさん:2017/03/10(金) 23:08:40.69
貝柱が入ってた頃は好きだった
ということは俺が目覚めたのはあの辺りか

736 :仕様書無しさん:2017/03/11(土) 00:26:19.26
センスあるやつはカップヌードルなんぞ食わん

737 :仕様書無しさん:2017/03/11(土) 00:30:41.49
じゃあなに食うんだよ!

738 :仕様書無しさん:2017/03/11(土) 00:48:48.80
coop noodle

739 :仕様書無しさん:2017/03/11(土) 04:28:46.78
ワンカップ noodle(お酒)

740 :仕様書無しさん:2017/03/11(土) 09:56:49.87
>>1がどの程度シンプルだといいのか?
どの程度例外を処理するとダメだといっているのか示していない。

程度で区分しようという問題を、
基準を示さず適当に言ってのける愚かさをみると
こいつ絶対にプログラマじゃなくてクズSEの典型だとわかる。

低知能がスレなんぞ立てるなバカたれが

741 :仕様書無しさん:2017/03/12(日) 12:05:57.01
>>9
マルチスレッドでなくてもいいのにマルチスレッドしてしまうのは初心者

742 :仕様書無しさん:2017/03/12(日) 12:06:11.87
能力の低い人、無知に気づいてない人ほど根拠のない自信に満ちあふれている。「ダニング=クルーガー効果」とは?

http://karapaia.com/archives/52191924.html

743 :仕様書無しさん:2017/03/14(火) 08:36:55.66
>>742
この言説を自己言及的だなと思い、2人以上のケースに拡大して、意識高い系に発展して考えてしまう人が、プログラミングセンスがある人

744 :仕様書無しさん:2017/03/14(火) 12:33:32.97
センス以前に自己言及の意味を学びなおして下さい

745 :仕様書無しさん:2017/03/14(火) 15:10:52.77
>>744
自己言及的なレスですね

746 :仕様書無しさん:2017/03/14(火) 20:16:38.13
「プログラムなんて誰でもできるでしょ?」

747 :仕様書無しさん:2017/03/14(火) 20:50:05.04
どんな仕事でも同じで、誰でもできるけど
数人に同じものを作らせても、絶対に同じものは完成しない
それも品質、信頼性という最も重要な部分に現れる違い

ド素人は、誰に作らせても同じものができると考えて
経験が浅い奴に作らせて、低品質なものを出して
客からクレームの嵐

748 :仕様書無しさん:2017/03/15(水) 22:13:04.25
みんなできるの度合いが違うからなあ

749 :仕様書無しさん:2017/03/15(水) 22:22:02.83
例えば、Jリーグみながら
「サッカーなんて誰でもできるでしょ?」
と言われてもねぇ。。。

750 :仕様書無しさん:2017/03/15(水) 22:35:15.20
ある機能の実現には手法が複数あってどれを選ぶか、どんな作りをするか
それらの違いだけで品質は大きく変わり、環境によっては問題を起こす
だけど決してバグではなく間違ってもいない、ただ最善ではない
そこが経験者と素人の違い

751 :仕様書無しさん:2017/03/15(水) 22:37:36.83
素人はそもそも、手法が無数にあることさえ知らないから
最善もクソもないわけだけど

752 :仕様書無しさん:2017/03/15(水) 22:41:23.60
あ、分かりにくかったかもな
>>750で俺が言ってるのは
最善の実装が常に最善の結果であるとは限らない
って事な

753 :仕様書無しさん:2017/03/15(水) 22:42:29.34
>>752
え?

754 :仕様書無しさん:2017/03/15(水) 22:44:34.92
>>752
あんたレス番間違えてるぜ、>>747>>750-751は俺

755 :仕様書無しさん:2017/03/15(水) 22:45:55.89
>>754
え?

756 :仕様書無しさん:2017/03/15(水) 22:48:10.23
突然現れた成りすましの>>752が何を言ってるのかがわからない

757 :仕様書無しさん:2017/03/15(水) 22:50:22.55
問題が起きたらバグだろ
センスあれば経験有無に関わらず問題起こさない

まあでも言いたいことはわかる

ついでに加えると、
センスないやつは環境変わっても過去の成功例を推し通して問題起こす
(経験を仇にする)

758 :仕様書無しさん:2017/03/15(水) 22:50:56.51
>>756
いやw冗談は程々にしとけよw
>>750は俺だからw

759 :仕様書無しさん:2017/03/15(水) 22:52:43.59
>>758
ここまで全部ひとり

760 :仕様書無しさん:2017/03/15(水) 22:53:49.85
>>757
は?

761 :仕様書無しさん:2017/03/15(水) 23:02:31.04
>>758
そういうのいいから

>>757
バグじゃなくても問題は起きる
事実上回避が不可能な問題などいくらでもある
ただ完全回避はできなくても、別の手法なら
もっと信頼性を高められるというもの

762 :仕様書無しさん:2017/03/15(水) 23:10:32.32
>>761
意味がわからん
そこまでして他人に成りすまして何がしたいんだお前?
なんか怖くなってきた

763 :仕様書無しさん:2017/03/15(水) 23:14:18.05
>>757
あとセンスはもちろん重要だけど、机上ではない実経験も重要ね
センスと経験、両方とも備わっていない人間は、今のところ素人

まあ本当にセンスがあれば必然的に経験も人の何倍、何十倍も身に付くから心配ない

764 :仕様書無しさん:2017/03/15(水) 23:22:07.92
>>762
阿呆か?
なりすましとか言うならまずは酉つけろ

765 :仕様書無しさん:2017/03/15(水) 23:41:19.45
>>761
いやだから問題になった時点でそれはバグなんだよ
仕様にない動作、あるいは設計時の考慮漏れであり、
信頼性もへったくれもない

>>763
センスあるやつは机上で片付かない事案を事前に動かして確認するんだよ
問題になるまで放置したりしない

と、ここまで書いて
問題という言葉のレベルに対して認識がズレてる気がした

766 :仕様書無しさん:2017/03/27(月) 23:56:32.66
ハード故障が原因のエラーとかは
問題だけどバグではないな

767 :仕様書無しさん:2017/03/28(火) 01:19:05.94
>>765
> 問題という言葉のレベルに対して認識がズレてる気がした

その通り。お前が問題という言葉を分かっていない。

問題という大きなグループの中にバグが含まれる。
バグの中に問題が含まれるのではない。

問題の原因はバグ以外もいろいろある。
だから問題が発生したからと言ってバグというわけではない

768 :仕様書無しさん:2017/03/28(火) 06:04:49.16
>>765
レスに気付かんかった

バグと不具合は違うんだよ?
熟練者は使い分けてる
君は混同して、起きた問題を全てバグと総称してるようだけど

769 :仕様書無しさん:2017/03/28(火) 11:26:36.24
>>768
そんなのただの言葉の定義の問題

770 :仕様書無しさん:2017/03/28(火) 11:28:09.70
>>766
ハードウェアでもCPUの回路の問題等はバグと呼ぶのが普通。

771 :仕様書無しさん:2017/03/28(火) 11:49:39.78
>>770
今はエラッタとは言わないの?

772 :仕様書無しさん:2017/03/28(火) 12:03:14.20
なんか、請負と派遣で認識が異なりそう

773 :仕様書無しさん:2017/03/28(火) 14:16:29.22
>>771
専門的にはそういうけど、一般的には通じないからエラッタとはいきなり言わない。

774 :仕様書無しさん:2017/03/28(火) 14:20:27.30
バケラッタ

775 :仕様書無しさん:2017/03/28(火) 15:22:49.69
>>773
少なくともバグとは言わないが?

776 :仕様書無しさん:2017/03/28(火) 17:41:10.90
>>773
一般的ってなんだ?
ここ何板?

777 :仕様書無しさん:2017/03/28(火) 18:07:29.41
だいたいバグという言い方はもともとスラングだぞ。

778 :仕様書無しさん:2017/03/28(火) 18:48:20.20
不具合ってのも、仕様上の矛盾から実装ミスやら物理的なインターフェイス間の解釈の齟齬や曖昧性解決の失敗といったコアな部分まで含めると割と広いからな。

779 :仕様書無しさん:2017/03/28(火) 19:24:52.36
>>778
不具合という言い方を嫌う人間はいるが、一般人向けには不具合ということになっているのを知らないやつが多い。テレビのニュースでプログラムミスとか言われるよりまし。プログラムミスってどうせ仕様バグなんだろうけど、下の責任にするためにそういう発表になってるんだろうな。

780 :仕様書無しさん:2017/03/28(火) 19:25:50.47
>>779
は?

781 :仕様書無しさん:2017/03/28(火) 19:49:30.65
バグってIT用語だろ
一般人は知らん人も多い

782 :仕様書無しさん:2017/03/28(火) 20:44:58.07
>>773
一般でエラッタだが

783 :仕様書無しさん:2017/03/28(火) 21:06:16.47
>>781
ゲームやったことある人なら知ってるだろ

784 :仕様書無しさん:2017/03/28(火) 21:06:23.03
世間一般のバグの定義を見てみようか?

http://e-words.jp/w/%E3%83%90%E3%82%B0.html
> バグとは、コンピュータプログラムに含まれる誤りや不具合のこと。

https://kotobank.jp/word/%E3%83%90%E3%82%B0-7302
> バグとは虫の意味で、パソコン用語ではプログラムの中の誤りのこと。

http://it-trend.jp/words/bug
> 元は虫を意味する英単語だが、転じてコンピュータプログラムの誤りや欠陥を意味する。

これ以降、この定義を前提に話すことにしようね。
それが出来ないって人は、まず、このレスは間違いであると書いて
その根拠も示すこと

785 :仕様書無しさん:2017/03/28(火) 21:21:25.96
Bugってハニー♪

786 :仕様書無しさん:2017/03/28(火) 21:43:27.35
>>784
問題は全てバグつってる奴は、この定義から大きく外れてるわけだ

787 :仕様書無しさん:2017/03/28(火) 21:46:34.35
「障害が置きました!」

「障害の原因は何だ!」

「問題が発生してました!(意訳 プログラムの不具合のこと)」



「問題が原因か!」

「はい、問題です!」

788 :仕様書無しさん:2017/03/28(火) 21:54:38.84
昔、入ってきた一人の新人が問題を見境無くすべてバグと言ってたな。
ウチに非がないものや、そもそもバグじゃねえものもあるんだから
不具合と言い直すよう教育したことあるわ。
バグじゃねえのに客に「バグです」とかいきなり言って怒らしたりな。

789 :仕様書無しさん:2017/03/28(火) 21:56:18.08
もちろん不具合でもないものもあるし
とりあえず客をキレさせるバグ表現はやめとけと。

790 :仕様書無しさん:2017/03/28(火) 22:23:00.67
>>788
新人はしかたない
客にいうのはマズいね

791 :仕様書無しさん:2017/03/28(火) 22:33:42.54
バグですと言って怒らせた手前、不具合修正という名目の無料仕様変更

792 :仕様書無しさん:2017/03/29(水) 04:13:52.50
>>791


793 :仕様書無しさん:2017/03/29(水) 05:54:35.94
>>792


794 :仕様書無しさん:2017/03/29(水) 06:29:49.55
>>793
??

795 :仕様書無しさん:2017/03/29(水) 12:02:52.67
>>779
一般向けの話してないのでは?
不具合、と言わないよ。テレビのニュースだと「問題」「トラブル」でとにかくぼかす。
不具合だってテレビで断定するのは、事情通やら研究者とやらが出てコメントする時くらい。

下の責任にする訳ねえじゃん。
そんな事してたらまた同じ事するだろ。
だからこっちで総合して事実が発生した場所をはっきりさせて、顛末書を書くんだよ。
そのために問い詰められるのを、責任転嫁されそうだからごまかそう、ってされると、改善不能として取引停止するしかない。
お前下流しかやってないの?

796 :仕様書無しさん:2017/03/29(水) 12:18:05.78
新人に不用意な一言で招いた損害額(工数)をちゃんと教育しとかんと。
繰り返すよ。

797 :仕様書無しさん:2017/03/29(水) 12:35:59.64
>>796


798 :仕様書無しさん:2017/03/29(水) 12:37:36.41
>>795
不具合は事象、バグは原因に属するもので
それぞれ全く別の概念です。

799 :仕様書無しさん:2017/03/29(水) 12:41:49.66
>>798


800 :仕様書無しさん:2017/03/29(水) 12:44:07.64
>>798
阿呆だろ?

801 :仕様書無しさん:2017/03/29(水) 12:51:28.16
>>798
こういう馬鹿が言葉を乱すんだな

802 :仕様書無しさん:2017/03/29(水) 12:54:47.51
オレオレ属させワロタw

803 :仕様書無しさん:2017/03/29(水) 14:13:44.18
正しいよ。わかんない奴がバカ。

804 :仕様書無しさん:2017/03/29(水) 14:21:48.45


805 :仕様書無しさん:2017/03/29(水) 15:09:40.25
ここまでの流れで、万人の合意を得られる定義は存在してないことを理解出来ないやつはセンスがない

806 :仕様書無しさん:2017/03/29(水) 15:12:54.82
そもそも不具合ってのは差別用語でまともな会社なら使用禁止のはず

807 :仕様書無しさん:2017/03/29(水) 16:14:14.78
またバカが来たぞw

808 :仕様書無しさん:2017/03/29(水) 17:57:48.32
辞書で引くとかすら思いつかない奴は常識が欠如してる

809 :仕様書無しさん:2017/03/29(水) 17:59:12.75
>>808
IT技術者くらいだよ、ググるのは。IT技術者でもまったく調べもせずに聞いてくるのはいるけどw

810 :仕様書無しさん:2017/03/29(水) 17:59:17.70
>>806
有名な話だな

811 :仕様書無しさん:2017/03/29(水) 18:01:56.09
>>810
あほ

812 :仕様書無しさん:2017/03/29(水) 18:06:22.74
>>811
無知が必死w

813 :仕様書無しさん:2017/03/29(水) 18:11:31.90
不具と不具合が同じ語源だと勘違いしてる阿保がいるからこうなる。

不具合は具合がよくない、具合がいまひとつだという意味なのに、日本語がわからない連中は、不具と不具合を混同している。

814 :仕様書無しさん:2017/03/29(水) 18:38:19.94
>>813
ググればわかることを得意気にひけらかしてもね
現代において不具合は差別用語になってしまっている現実
語源がーとか騒いでも弱者様に噛みつかれたらおわり

815 :仕様書無しさん:2017/03/29(水) 18:48:23.84
>>814
あほ

816 :仕様書無しさん:2017/03/29(水) 18:52:06.73
センスあるプログラマの発言とは思えない

817 :仕様書無しさん:2017/03/29(水) 18:53:22.01
>>814
差別用語ではない。

818 :仕様書無しさん:2017/03/29(水) 19:21:59.23
うちの会社は不適合に直したよ。
3年くらい前に。
不具合票も不適合票に。
ちなみに今は障害も禁止されてる。

819 :仕様書無しさん:2017/03/29(水) 19:46:11.71
お前はバグをドラゴンと呼ぶのか?

820 :仕様書無しさん:2017/03/29(水) 19:53:29.99
FireFoxのインスペクタ便利すぎ
なにこれ

これない時代みんなどうやってスタイルシートとかHTMLつくっとったん
むりだろ

821 :仕様書無しさん:2017/03/29(水) 20:05:07.27
>>818
あほだ・・・

822 :仕様書無しさん:2017/03/29(水) 20:15:19.33
>>821
底辺の派遣さんには関係ないことだから(汗w

823 :仕様書無しさん:2017/03/29(水) 20:19:12.60
ダメな顧客と付き合う必用がない

824 :仕様書無しさん:2017/03/29(水) 21:24:02.29
この業界で普通に働いてりゃ不具合だろ
不具合報告書、不具合リスト
障害というところもあったかな
少なくとも書類にはバグとは100%書かない

825 :仕様書無しさん:2017/03/29(水) 21:28:45.39
>>824
富士通は普通に書いてたような気がする
書きたくなくてもドロップダウンで選ばせるからかかざるをえない

826 :仕様書無しさん:2017/03/29(水) 21:29:29.57
>>824
認識狭すぎ

827 :仕様書無しさん:2017/03/29(水) 21:39:04.79
>>826
認識とかじゃなく事実
ビジネス書類に「末尾」じゃなく「ケツ」と書くようなもんだぞ

828 :仕様書無しさん:2017/03/29(水) 21:42:58.43
産んだ親が子を監視して最期は殺す

とか、仕様書には書かないな

829 :仕様書無しさん:2017/03/29(水) 21:47:54.04
IT用語は陰謀用語

830 :仕様書無しさん:2017/03/29(水) 21:59:49.96
不具合なんて差別用語使ってるとISOの定期監査で不具合になっちゃうw

831 :仕様書無しさん:2017/03/29(水) 22:00:23.13
IT業界用語地味に物騒なの多い

キックが実行なのが腑に落ちない

832 :仕様書無しさん:2017/03/29(水) 22:01:59.29
>>828
プロセスを殺すと書かれた仕様書を実際に見たことがある

killだから間違っちゃいないし当然通じるだろうけどな
終了させるとか書きようはあるだろうに
社会人なんだから学生用語はやめような

833 :仕様書無しさん:2017/03/29(水) 22:05:46.87
>>830
人間相手じゃなきゃ差別用語にはならんぞ
その説明だと、通信障害も差別用語になる

834 :仕様書無しさん:2017/03/29(水) 22:17:57.25
>>833
ググれば監査で理不尽に差別扱いされた事例がいっぱいでてくる

835 :仕様書無しさん:2017/03/29(水) 22:27:24.83
>>827
知識狭すぎ

836 :仕様書無しさん:2017/03/29(水) 22:28:36.21
>>834
アホは発言しなくていいよ

837 :仕様書無しさん:2017/03/29(水) 22:32:24.68
>>834
お前も、1万個とかマンゴーとか、特に何でもない言葉に過剰反応をする
モンペのようなクレーマーの1人なんだな

838 :仕様書無しさん:2017/03/29(水) 22:33:27.03
>>835
社会知らなすぎ

839 :仕様書無しさん:2017/03/29(水) 22:34:46.34
だから派遣さんには関係ない話なんだから
無理に入ってこなくていいですよ
上場企業の正社員限定でお願いします

840 :仕様書無しさん:2017/03/29(水) 22:37:49.61
>>827
経験なさすぎ

841 :仕様書無しさん:2017/03/29(水) 22:38:38.11
>>840
スキル低すぎ

842 :仕様書無しさん:2017/03/29(水) 22:45:35.10
派遣どうこうじゃなくて業界の違いじゃね

843 :仕様書無しさん:2017/03/29(水) 22:55:02.07
富士通のバグ表ドロップダウン

種別:バグ|仕様誤り
原因:コーディング誤り|仕様の読解ミス|仕様書の誤り(根拠の書類提示、別の手続き、承認等が必要)
根本原因:作業者のスキル不足|監督者の監督不行届|環境の問題(上で最初の2つを選ぶと選べない)

こんなかんじ
下っ端にはふつうにバグっていう

844 :仕様書無しさん:2017/03/29(水) 22:59:07.40
>>841
あほ

845 :仕様書無しさん:2017/03/29(水) 23:43:19.74
日立グループは障害票のことをB票と言っている。これは単に日立お得意の略語。

846 :仕様書無しさん:2017/03/30(木) 01:36:26.64
自動車系は納品する書類でも不具合だな
もちろんその中に分類はあるけどな

847 :仕様書無しさん:2017/03/30(木) 02:42:03.77
天ぷら定期券を買うとだな
期間中これがずっと130円で食えるわけだ
http://i.imgur.com/ZgsM4hn.jpg

300円で買えるはなまるうどん春の天ぷら定期券とは
https://www.hanamaruudon.com/tempurapass2017spring/

848 :仕様書無しさん:2017/03/30(木) 10:43:27.28
>>832
TERMで終了願うのか、KILLで殺すのかは、全然違う話だよね。

849 :仕様書無しさん:2017/03/30(木) 10:44:04.23
>>845
IBMのパクリだろ。

850 :仕様書無しさん:2017/03/30(木) 12:23:56.71
言葉ひとつで損害発生するんだから気をつけろよ、というだけの話に良くそこまで盛り上がれるな。

851 :仕様書無しさん:2017/03/30(木) 12:48:25.85
慰安旅行と言ったら韓国人が怒り狂ってた

852 :仕様書無しさん:2017/03/30(木) 13:00:06.93
嘘つけ

853 :仕様書無しさん:2017/04/13(木) 21:26:27.94
受託企業にいるプログラマーは全員センスないと思う
下請けはゴミ

854 :KAC:2017/04/14(金) 21:24:47.63
>>853
その仮説が正しいのなら、下請けという概念は滅びてるぞ

855 :仕様書無しさん:2017/04/14(金) 22:11:01.86
なんという支離滅裂な下請け脳

856 :仕様書無しさん:2017/04/15(土) 03:01:47.42
みんな何の開発してるの?
ゲーム? 業務システム? それとも組み込み系?

857 :仕様書無しさん:2017/04/15(土) 07:05:37.48
アナル系

858 :仕様書無しさん:2017/04/15(土) 07:42:37.34
ウケかタチか
それが重要だ

859 :仕様書無しさん:2017/04/16(日) 00:24:05.13
融通のきかないモーホーに用はない

860 :仕様書無しさん:2017/04/25(火) 17:14:58.20
センスなくても可

861 :仕様書無しさん:2017/04/25(火) 21:38:36.53
優 良 可 不可の4段階があってだな

224 KB
新着レスの表示

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :


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