07/02/01 03:24:15
ブラウザ固定？
JavaScript？
Ajax？
ASP？
Web2.0？
車輪の再発明？
前スレ
ｽﾚﾘﾝｸ(prog板)
2:仕様書無しさん
07/02/01 04:35:28
Webアプリってなんつーか、予備校みたいな感じがすんだよな。
ほんとは大学に行ってるはずの俺には、ここはホントの住まいじゃない、仮住まいなわけ。
いつか出て行くことは分かってるってか、早急に出て行かなければならない。
出て行きたいんだけど、何か流れ的にそんな感じで今ここにいる、みたいな。
最近のAjaxとかそういうクソな流れを見てると、そんな気分になる。
ごめ、予備校通ったことないんだけどｗ
3:仕様書無しさん
07/02/01 06:31:58
それ、VBやCOBOLでも同じ事言ってるﾔﾂがいる。ｗ
確かに大きな流れってのは存在するんだが、
それに流されて生きてるアマちゃんの言い訳なケースがほとんどだな。
4:仕様書無しさん
07/02/01 10:31:39
おれ、Webでこったことするの大好き
Ajaxとかもう最高！！
5:仕様書無しさん
07/02/01 11:52:57
ある意味素人でも遊べる技術の集合体だからなぁ。
VB厨も好きそうな分野だよ。
6:仕様書無しさん
07/02/01 12:51:00
VBより惨いだろ？
PHPなんてよおおおおっっっっぽど上手いつくりじゃないと、コードグダグダ。
7:仕様書無しさん
07/02/01 13:21:04
第二のCOBOLだ＞PHP
イージー過ぎる言語仕様故に腐れプログラマが量産される。
このあいだヘルプで入ったプロジェクトで初めてPHPを触ってそう感じた。
$_HOGE つうグローバル変数をvar_dumしたらブラウザがクラッシュｗ
ファイルに吐かせたら16MBにもなりやがった。
中身は･･･
DBの全項目だの謎のシリアライズデータ･･･etc
SQLに任せりゃいいのに
データは全て「SELECT * FROM～」で配列にブチ込んでからソートやマージやフィルタリングをやる。
DBは汎用ストレージか？
CSVファイルでも使った方が性能上がるんじゃね？
PHP界ではこれが常識 なのか？
グローバル配列変数に何でもブチ込むのが正しいのか？
PHPのプロセスメモリも加味したら、同時50リクエスト位でサーバ落ちるんじゃねえか？
つう事を指摘したら「webではこれが常識です」と言われた。
制御系からweb系に転職したんで、メモリ貧乏性が抜けない･･･
あっちはメモリ8KBの監獄だったもんで･･･
周囲の奴らが全員敵に見える。
もうやだ。
8:仕様書無しさん
07/02/01 13:53:35
>>1
「戻るボタン」と「サブミット二回押し」も挙げてほしかったよ
9:仕様書無しさん
07/02/01 13:58:50
>>7
> つう事を指摘したら「webではこれが常識です」と言われた。
> 制御系からweb系に転職したんで、メモリ貧乏性が抜けない･･･
> 周囲の奴らが全員敵に見える。
> もうやだ。
俺はインターネットが流行りだした頃に、Perl4使って、ライブラリ無しのフル自作で
CGI掲示板やらWEBアプリを作ってたことのある人間なんだが…。
俺から見ても、君の語るPHPの世界は「異常な光景」に見える…。
10:仕様書無しさん
07/02/01 14:01:11
PHP房もJava房と同じだな。
まともなのは.net房だけだ
11:仕様書無しさん
07/02/01 14:07:21
かきゃーいんだろ？って感じのソースが多い度合い。
PHP、Perl ＞ VB6 ＞ C ＞ その他
結構C使いもそういう部分の人が多い。工夫も無くべた書き。
12:仕様書無しさん
07/02/01 14:31:47
>>7
そんなのWEBの常識でもなんでもないので信じないでください
16MBの変数なんてグローバルじゃないとしてもおかしい
DBからとってきたもんをそのまま連想配列に入れるのはおかしくないけど、
もちろん適切なSQL文書いて
必要な分だけとってくる。
そのプロジェクトの連中SQL文かけないからそんなことしてるんじゃね？
クラサバで、クライアント側でソートとかフィルタリングするのは、よくあるけどね。
サーバに負担かけたくない場合｡
13:仕様書無しさん
07/02/01 14:39:36
最近開発経験がない会社がWEB開発請け負ったりするから、
今までの常識が全く通じない場合があって怖い
14:仕様書無しさん
07/02/01 14:42:36
WEBって本来はクラサバ以上に知識が必要なのにね。
まっとうなものを作ると思ったら。
15:仕様書無しさん
07/02/01 14:44:17
それなのに
それなりの技術しかなくても見栄えは簡単に調整できるから
ぐだぐだなwebアプリが絶えないんだろうね
16:仕様書無しさん
07/02/01 14:46:50
世の中のWebアプリ全部おれが作れば
すばらしいものばかりになるのになー
17:仕様書無しさん
07/02/01 18:39:49
実際はWebは簡単じゃないんだが、簡単そうに思い込んでいる
素人がアレコレ知ったかされるとグダグダになるんだろう。
18:仕様書無しさん
07/02/01 18:41:40
PHPの案件やったが型が厳密でないというのは非常に怖くめんどくさい
WEBに限らないけどWEBの言語は型があいまい過ぎだわ
ASP.NET信者じゃないけど、そういう意味では革新的だと思う
19:仕様書無しさん
07/02/01 18:44:06
ASP.NET AJAX 1.0ってどうやって使うの？
素人でもわかる解説HPありますか？
20:仕様書無しさん
07/02/01 18:52:50
>>19
・・・・(；´∀｀)
スレ違いもはなはだしい・・・・
MSいってこいよ
入れ方とかサンプルもあるだろ？
21:仕様書無しさん
07/02/01 18:54:25
「モデル層の設計」という概念を持たない自称Webプログラマっているよね？
22:仕様書無しさん
07/02/01 20:59:29
ビジネスロジックはモデルである。
23:仕様書無しさん
07/02/01 21:04:36
>>12
SQLが書けなくてもまともにO/Rマッピングが出来ていればなんとでもなるはずなんだけど…
結局、設計がまともに出来てないからそんなことになるんじゃないかと思う。
あるいは使ってる言語をまともに使いこなせてないか。
24:仕様書無しさん
07/02/01 21:08:41
需要の急増でちょっとPCに詳しいフリーターみたいなのまで投入される
Webアプリ業界ではザコにいちいちキレていても仕方がない。
組み込み系も近い将来そうなる。
25:仕様書無しさん
07/02/01 21:12:24
この業界、SEの素人率が異常に高くて発狂する。
パッケージ系に逃げようと最近こころに決めました。
26:仕様書無しさん
07/02/01 21:28:13
>>23
俺も設計と思う
というのもうちの会社でもPHPチームで似たようなことあるけど
設計が上手くできてない場合が圧倒的。最初の段階でこけてるからもう
ドミノ倒し状態になってる
27:仕様書無しさん
07/02/01 21:53:57
>>7
ﾜﾗﾀ
28:仕様書無しさん
07/02/01 23:27:16
>>7
> SQLに任せりゃいいのに
> データは全て「SELECT * FROM～」で配列にブチ込んでからソートやマージやフィルタリングをやる。
まぁ、ある意味高度な事してるね。
29:仕様書無しさん
07/02/01 23:53:55
>>23, 26
6､7年以上前にWEBやってたから良くわかんないんだけど、
最近はSQL文とか自動的に書いてくれるライブラリとかがあるの？
それとも、ちょっとできる人がＤＢアクセスをラップするクラスでも作るってこと？
最近はどんなやり方が主流なんですか?
30:仕様書無しさん
07/02/01 23:58:36
過度のチューニングの結果、オンメモリDBをPHPで実装してしまったのかもしれない。
なんつって。
31:29
07/02/02 00:07:19
今いろいろ調べて自己解決しました
お騒がせｽﾏｿ
32:仕様書無しさん
07/02/02 00:14:19
アプリサーバ－DBサーバ
別配置でDBサーバがプア or いろいろ他部署のシステムにも情報提供してる場合
あんま複雑なSQL（副問い合わせやらJOINやら）は使うな、っておたっしがある場合がある。
そんな時はしたかないからメモリにとってから特別な抽出やらソート集計その他をがんがんやる、って場合もあるけどね。
某広告会社のWebサイトでは昔そういうルールがあった。
APサーバ1
APサーバ2 DBサーバ（２重化構成）
APサーバ3
・・・
なのでDB側に負荷かかる事させると他部署からクレームが
33:仕様書無しさん
07/02/02 00:16:30
>>32
それはひどいね
同一サーバに複数システムが同居してるとやだなー
不具合合ったりすると、あらぬ疑いかけられたり
34:仕様書無しさん
07/02/02 00:27:35
正規化という言葉のない国からやってきたようなデータ
半期ごとに内容が変わるマスタ
半期ごとに名前が変わるテーブル
こんなDBを元にしてWebアプリ作って欲しいと言われました。
いじめでしょうか？
なまじ開発なんて出来ない方が幸せだったかもしれないと思った。
35:仕様書無しさん
07/02/02 00:34:47
>>34
日本語でOK
マスタの内容が変わるのは当然だと思うが、何か大変なの？
テーブルの名前変えるのはなぜ？
そのDBを元にするだけなら、好きなように作り変えれば良いんじゃねーの？
36:仕様書無しさん
07/02/02 00:36:40
>>34
意味は分かる
とりあえず開発時点でのDB仕様で作るしかないのではないだろうか。
37:仕様書無しさん
07/02/02 00:42:38
>>35
なんでテーブルの名前変えてるのかはオレもよくわからない。
DB新しく作れるなら楽なんだけどねぇ。
マスタがマスタになってないって言った方がいいのかなぁ
適当に更新してたみたいで同じ部課名でコードがいろいろあったりする。
38:仕様書無しさん
07/02/02 01:23:04
そこは名寄せとかコンサル的な提案を進めるべきだと思うんだが、
糞SEが自分の負担が増えるのを嫌がって、プログラマに丸投げする事が多いと思う。
で、運用がえらい目にあって、結果的には赤字。
営業、SEは知らん振り。
39:仕様書無しさん
07/02/02 01:24:11
何つーか、それ作るのも運用するのも無駄にスキルが必要だな・・・
40:仕様書無しさん
07/02/02 01:27:37
＞半期ごとに内容が変わるマスタ
内容と言われても・・・
規則が変わるのかフィールドが変わるのか・・・
ビュー噛ませるなり誤魔化し方はあろう
＞半期ごとに名前が変わるテーブル
こっちは設定ファイルに名前持たせときゃ1分で対応可能だろ
41:仕様書無しさん
07/02/02 01:29:13
>>38
DBを共用するんだべ。
別に作られた稼働中のシステムまで変えなきゃムリなんじゃねーの？
42:仕様書無しさん
07/02/02 12:47:56
>>34
RDBじゃなくXMLにすればいいよ。
43:仕様書無しさん
07/02/02 12:53:22
>>34
テーブルのPrimaryKeyの一番上に、年と上期／下期を入れれば、テーブル名の変更は
いらないのかもしれないが、
マスタの内容も変わり、正規化もされていないのだと
半期ごとにJOINの条件も変わるということかな。よくわからんが・・・
44:仕様書無しさん
07/02/02 12:56:57
>>34
> 正規化という言葉のない国からやってきたようなデータ
> 半期ごとに内容が変わるマスタ
これは良くある。ｶﾞﾝｶﾞﾚ。
> 半期ごとに名前が変わるテーブル
これだけもう一回説明できないか？良くわからんのだが・・・
45:仕様書無しさん
07/02/02 13:26:18
>>29
自動的に書いてくれるクラスライブラリがあったら
↑の人達が言ってる正規化とか出てこない
と思われますがどうっすか？
46:仕様書無しさん
07/02/02 17:16:07
意味不明
47:仕様書無しさん
07/02/02 17:35:29
>>45
ぬぅ・・・分からん。
もちっとkwsk。
48:仕様書無しさん
07/02/02 22:26:58
TBL_2006_4みたいなテーブルが半期ずつだったら笑えるな
49:仕様書無しさん
07/02/03 00:37:06
データベースの設計はどうやら思ったより専門職らしいよな。
漏れは器用貧乏かつ設計&プログラムな人間なので、
そこそこにリレーショナルな設計するけど、
Excelマンセーとか年配なCOBOLerだと、むちゃくちゃなDB設計する
とマジで感じるよ。
50:仕様書無しさん
07/02/03 00:39:37
>>32
こういうの割と多くない？
クラスタ化に乗り気にならない人多いし
51:仕様書無しさん
07/02/03 00:46:33
スマートクライアント - SOAPサービスなら、
DelphiのDataSnapで作るのが簡単
52:仕様書無しさん
07/02/03 01:47:18
>>32
読み取り専用のレプリカなりを作って，Webの照会系プログラムとかは
優先的にレプリカサイトを使う，ってのが基本なんじゃないの？
レプリカサイトならかなり無茶な検索処理走らせても問題ないし．
後，半期毎にテーブル構造が変化するDBなら，その都度DDL流して
テーブル作りなおすってのはどうだろう？
それに併せてアプリケーションも半期毎に自動生成．
自律型プログラミング業務システムのできあがり，っと．
53:仕様書無しさん
07/02/03 08:00:32
>>32は大雑把な説明なんだろうし、実際の業務によってかわるだろうけど、
APの鯖x３でDB鯖x2はちょっと不思議だよな。
>>52の意見とカブるけど、仮に５台使える鯖があるならAP鯖をクラスタにして
DB鯖をマスター更新系x1で照会系x2にする方がいいとｵﾓ。
AP鯖はキャッキュが効く様にドカドカメモリ積め。まあサーバーのメモリは
つめるだけ積んだ方がいい。
まあ、パフォーマンスが出なくて、営業やマネージャーがこういう構成を
提案できない時点ででそもそもWeb系のシステム組むのは
ヤめといた方がいいんだが。
なんだかんだでWeb系は広く深く知識と経験が必要なんだろう。
54:仕様書無しさん
07/02/03 09:54:28
ちと逸れるが、こういう鯖運用についての著書って何かいいのある？
55:仕様書無しさん
07/02/03 20:08:53
スレ汚しすま（自分と同じトラブルにあってサポートに「そんな事例はありません」といわれ
泣き寝入りしている人の為に以下の情報を残します。）
J-COMが提供しているマイシールドがバージョンアップされたがそれを適用した所、
・マシン終了時、ハングアップして終了しない
・次のマシン起動以降、３～５分でsvchost.exeが死にマシンがまともに動かなくなる。
（マウスカーソル以外動かない状態になる。）
またIEなどでインターネットを見ていたとして、見えなくなってしまう。
なんとかマイシールドをアンインストールしたが、それでも挙動はおかしいまま変わらない。
WindowsXPHomeを再インストールしまともに動いている所に、またマイシールドをインストールしたら
また同じ挙動になった。
※ マイシールドが入っている状態で、無効化すると５分以上過ぎてもまともに動いていた。
こんな現象に出会った方、J-COMにちゃんとクレームしましょう。
（クレームが入っていない、と言い張っているが、少なくとも私はクレームしました。）
56:仕様書無しさん
07/02/03 21:38:18
マルチポスト野郎は氏ね
57:仕様書無しさん
07/02/03 22:48:28
>>54
そこらの情報誌なら>>52-53程度の事は書いてあると思うが・・・。
職場にあわせて構成・運用はそれぞれ違うから、
まともと思われるSIerに相談汁
ただ、まともSIerがかなり希少なのでアレだが・・・。
漏れの経験ではIBMの子会社とか日立・三菱の関連会社とかはスゲー最悪な
構成の見積もりもってくるからなー。
58:仕様書無しさん
07/02/03 23:53:34
Webアプリっていまだにjavaが多いの？
javaに不向きなアプリでもjavaを使ってる感じするんだけど。
59:仕様書無しさん
07/02/04 02:03:28
ヤフオクのオークション終了時刻はJavaすててFLASHにしてくれ
60:仕様書無しさん
07/02/04 08:24:39
Javaが不向きでもJavaで出来るならそれでいいんじゃね？
別に漏れ個人としてはC++で作ってもいいが、単なる嫌がらせと
思われるだろうし。
61:仕様書無しさん
07/02/04 10:10:29
>>60
>Javaが不向きでもJavaで出来るならそれでいいんじゃね？
もう分かりきったことだけど
中小規模とか、頻繁に変更が入るようなものは、javaは不向だろ。
java技術者とかいうのが多いとかいうのが理由らしいし、
フレームワークに従えばまあそれなりには出来るんだけど、
現実は2次でゲッティー確定らしいじゃん。
62:仕様書無しさん
07/02/04 13:11:18
YahooはJavaApplet使ってる珍しいサイトだ
63:仕様書無しさん
07/02/04 13:32:07
＞現実は2次でゲッティー確定らしいじゃん。
じゃん、って脳内妄想で言語否定論をﾓﾅｰ
だったら藻前はどんな言語で開発するんだよ？
COBOLとかVBなら保守性ｻｲｺｰとかヌかしそうで怖いんだが。
それに頻繁に変更が入る案件ほどJavaの方がありがたい気がする。
EclipesとCVS辺りを使うのが前提だが。
64:仕様書無しさん
07/02/04 15:01:14
言語によってそんなに保守性って変わるかなー
言語ってよりは設計だとおもうが
65:仕様書無しさん
07/02/04 15:12:43
うーん、クソ設計、オレ設計になりやすい（許してしまう）言語は
言語として保守性が低いと言えるんじゃないかな？
俺の中ではPerl,PHP,C++,VB,Java(withoutフレームワーク)がそれにあたると思う。
66:仕様書無しさん
07/02/04 17:47:45
誰がやってもそれなりの設計ができる言語があったら、業務系が真っ先に飛びつくだろうな。
67:仕様書無しさん
07/02/04 17:48:15
お前らWebStart広めようぜ！
Linuxにしてシンクライアントとか上手いこと言ってさ
68:仕様書無しさん
07/02/04 17:54:10
>>66
つJava with フレームワーク
現に飛びついてるわけだｗｗｗ
69:仕様書無しさん
07/02/04 18:01:54
>>65
結局、フレームワークを使うか使わないかじゃないの？？
PHPもフレームワーク使えばそれなりになるんだろ？
70:仕様書無しさん
07/02/04 18:02:48
>>65
全部じゃん ﾜﾛﾀ
71:仕様書無しさん
07/02/04 18:37:08
性的型チェックのあるJavaみたいな言語の方が，
型チェックの厳しくないPHPとかVB6よりも保守の時に楽だよ！じゃん？
72:仕様書無しさん
07/02/04 19:24:05
>>69
PHPのフレームワークはスタンダードと呼べるものが無いのでは？
73:仕様書無しさん
07/02/04 19:49:22
ぶっちゃけセキュリティを考えると、WEBアプリをなくす方向にいくしかないわけで。
かっこつけでWEBでやらないで、VPNでつないで普通にクライアントサーバーで
やればいいという話ではないか？
74:仕様書無しさん
07/02/04 20:28:59
そんなぶっちゃけた提案したら>>73は明日からクビだな。
75:仕様書無しさん
07/02/04 20:36:27
WEBの利点てやっぱインストールがいらないことかな。。
業務系のツールでたとえば
交通費清算、勤怠管理、経費清算とか
いちいちインストールするの嫌でしょ。
76:仕様書無しさん
07/02/04 20:51:30
webアプリはクライアントにインストールしなくていいってだけで
サーバへのインストールは結局鯖の再起動やら
サービス停止の案内やらで結構面倒
77:仕様書無しさん
07/02/04 21:10:49
俺らがやんのはいいんだよ
78:仕様書無しさん
07/02/04 21:19:42
>>76
サーバ側はクラサバでもwebでも手間かかるのは変わらないだろ。
79:仕様書無しさん
07/02/04 22:01:58
>>63
俺はc++とPythonメインで使ってて、管理画面程度のWebUIを
javaやLLで作ってるくらいだから、Webアプリにはそんな詳しくないんだけど、
javaは2次位からゲッティーになるのは良く聞くはなしだけどな。
>それに頻繁に変更が入る案件ほどJavaの方がありがたい気がする。
まあ、言いたいことは分かる。
でもそれはフレームワークにそった開発が出来ればの話だし、javaの得意分野とされる
大規模の場合はスキルの差も多く難しいんじゃないの？
そもそも中小規模ではjavaの面倒くささばかり目立つだろうし。
ある程度大規模の変更がある場合javaは手数がかかる分、思い切った変更も難しく
小手先修正が増えてゲッティーになりやすいのかなと、思うんだけど。
80:仕様書無しさん
07/02/04 22:06:56
>>78
DBにアクセス出来れば良いっていう簡単なのならそうだけど。
81:仕様書無しさん
07/02/04 23:02:54
つまり、インストールの手間が要らない仕組みさえあれば
WEBアプリなどいらないというわけだ
82:仕様書無しさん
07/02/04 23:09:28
>>81
でもClickOnceだっけ？あれって色々制約あるんで面倒とか聞くが。
83:仕様書無しさん
07/02/04 23:29:49
>>79
＞でもそれはフレームワークにそった開発が出来ればの話だし、javaの得意分野とされる
＞大規模の場合はスキルの差も多く難しいんじゃないの？
よーわからんけど、C++やPythonの大規模開発ではスキルの差は無くて、
ソースの保守性は問題無しって事でFA?
ぶっちゃけソースの保守性は使う人の能力が半分以上だろ。
サイクルRPGみたいな帳票出力言語ならともかく、
＞そもそも中小規模ではjavaの面倒くささばかり目立つだろうし。
EclipesとCVS辺りを導入して「Javaﾏﾝﾄﾞｸｾｰ」って言うなら、
他の言語は開発すら出来んと思うが・・・。
＞ある程度大規模の変更がある場合javaは手数がかかる分、思い切った変更も難しく
＞小手先修正が増えてゲッティーになりやすいのかなと、思うんだけど。
クラスの設計もしくは基本設計の話だろうな、この辺りは。
漏れ的にはプログラムのクラス・モデル設計よりかはデータベースのリレーショナルな設計の方が
重要に思えるんで、それほど言語でどーこー、って事はないなぁ。
まー、Javaだと開発鯖が相当にマシンパワーないとイラつくって点で
嫌いならそれは納得だけど、ゲッティーになるかどうかは人災な感がある。
84:仕様書無しさん
07/02/04 23:30:59
全国に散らばってるクライアントを総バージョンアップするのはいかにもきつそうだ。
あとコールセンターでは普通に１００クライアントとかのバージョンアップするけど、
それ全部やるのヤダ。
つかブラウザがちゃんと動く環境さえあれば、基本的には動くってのは随分楽。
アプリのインスコとWeb閲覧不具合じゃあ、リスクも全然違うし。
85:仕様書無しさん
07/02/04 23:32:02
x-www-form-urlencodedかmultipart/form-dataのどっちかをクライアントに実装すれば
ブラウザで作ろうがクライアントで作ろうがサーバからすれば一緒のこと。
RESTとかと一緒でもっと低レベルな規格から再構築してこうや。
86:65
07/02/05 00:10:33
>>70
おれは全然全部なんておもっちゃいないぜ。
Ruby,Python,Delphi,Lisp,Smaltalkがそれなりに美しい設計に対して強制力を持っていると思う。
（C#やDは完全にわすれてた。どーでもいい。）
87:仕様書無しさん
07/02/05 01:16:00
>>75 ：仕様書無しさん ：2007/02/04(日) 20:36:27
> WEBの利点てやっぱインストールがいらないことかな。。
WEBアプリは「インストールの手間が要らない」のがメリットだとは言うが、
それ以上のデメリットが多すぎるから開発者に嫌われているんだろ。
>>84
> 全国に散らばってるクライアントを総バージョンアップするのはいかにもきつそうだ。
クライアントをバージョンアップするのって、そんなにキツイの？
「禁断の壷」や「２ちゃんねるブラウザ」は自動でバージョンアップしてくれるだろ。
ClickOnceを使うまでもないと思うのだが。
88:仕様書無しさん
07/02/05 01:19:18
V2CをWebStartで使ってる身としては、こっち路線でいいんじゃねーかと思うんだよなぁ
89:仕様書無しさん
07/02/05 05:03:03
> WEBの利点てやっぱインストールがいらないことかな。。
所定のブラウザはインストールしてください。
セキュリティパッチが出たら即座に当ててください。
まーそれはさておき、蔵鯖でも蔵に自動更新機能付けたらWEBアプリとの差がなくなる気がするけど。
90:仕様書無しさん
07/02/05 06:44:57
Web利点だとライセンスの問題もあると思うが。
蔵鯖だとODBCドライバーにライセンスとかあったりする場合があるけど
Webだと特にそこらのライセンスは問題ないし。
あと個人的にpcommで画面作れって言われるよりはWeb＆フレームワーク
使った方が万倍楽に作れるからなぁ。
91:仕様書無しさん
07/02/05 10:44:02
>>89
> 所定のブラウザはインストールしてください。
> セキュリティパッチが出たら即座に当ててください。
オリジナルのクライアントなら、ブラウザのセキュリティホールに巻き込まれなくて済むよね。
> まーそれはさておき、蔵鯖でも蔵に自動更新機能付けたらWEBアプリとの差がなくなる気がするけど。
「差がなくなる」というより「大差が生じる」ような気がするｗ
92:仕様書無しさん
07/02/05 16:52:20
こうやってWEBアプリへの不平不満に耳を傾けていると、サーバー側への不満はあまり
聞かれず、クライアント側(ブラウザ、HTML、JavaScript、戻るボタン)への不満が
集中しているね。
サーバー側への不満ってないのかな？
>>85
> x-www-form-urlencodedかmultipart/form-dataのどっちかをクライアントに実装すれば
> ブラウザで作ろうがクライアントで作ろうがサーバからすれば一緒のこと。
> RESTとかと一緒でもっと低レベルな規格から再構築してこうや。
確かに。
WEBサーバーは、例えばJavaBeansのようなデータ集合体を発行するだけにして、
データ集合体をクライアントに展開すればいいだけだよね。
WEBサーバーとデータのやり取りができ、自動インストールと更新の可能なクライアントの標準規格
が確立できれば、現在のWEBサーバーは残したままで、マシなシステム構築が出来るよね。
ただ、最初のうちは、ブラウザと新クライアント両方で動くように作ってくれと言われそうな気もする。
93:仕様書無しさん
07/02/05 17:18:19
そういえば昔そんなシステム作ったな
元はWEBアプリだったんだけど、ブラウザ使うの面倒だからって
クライアントアプリになった｡自動更新と自動インストール(ブラウザでActiveX経由だけど）もあったな｡
94:仕様書無しさん
07/02/05 23:27:40
>>92
IISへの恨みなら数知れず。
・訳わかめな制限が多々ある事。
・中身がブラックボックスすぎて落ちるならともかくハングるともうどうにもな事。
普通のアプリならできる事がISAPI＆ASPになるとなんでもかんでもひっかかる。
そしてやれレジストリ、やれ匿名ユーザ、起動ユーザだアプリケーションプールだなんだと
いじりまくらないとまともに動作しない。
制限かけすぎだろ。
95:仕様書無しさん
07/02/05 23:51:35
ASPからレジストリいじれないからわざわざCOM作った
96:仕様書無しさん
07/02/05 23:54:05
サーバー側の不満かぁ。
WebSphereだと今の最新がV6.1なんだか、書籍ではV5.0かつ廃刊ってトコだろうか。
あのレスポンスの悪いWebのインフォメーションセンターはなぁ。
鯖の機能自体は悪くない。商用だから当たり前かもしれんが。
97:仕様書無しさん
07/02/06 00:37:34
現在２２歳、専門出でリクルートの紹介で今新たにＳＥへの就職を考えているものです。
でもココを除いた限りではあまりＳＥは良いものじゃないのかな…という印象も…
ＷＥＢアプリ系の仕事が良いかなとか思っていたんですが専門でで使い古されるとかまさに自分の事？みたいな書き込みがあったり‥これって本当なんですか？
リクルートでは仕事を紹介して利益を得る訳ですから良い事しか言わないので実際に働いてる人の意見聞きたいんです。
この仕事していて良かった事とかお勧めできる点ありますでしょうか？是非意見下さい
98:仕様書無しさん
07/02/06 01:02:33
>>97
オレ、このWebの業界でしかプログラマした事が無くて、
他の会社も何も知らないから普通の仕事ってどんなのかわかんないけど、
仕事内容って点では次々新しいフレームワークが出て楽しい最先端の業界だって最初思って、
次にだんだんミーハーで表面だけで踊らされてるよなーって思って、
最後は【まともな】リッチクライアント時代を夢想して糞HTMLを無気力にこねくり回す。
待遇については給料は極悪ではないが、納期と労働時間が極悪。
楽しいときは耐えられるが、Webに疑問を持ち始めたらもう続けられないと思う。
99:仕様書無しさん
07/02/06 01:03:24
>>97
こっち見て味噌
ｽﾚﾘﾝｸ(job板)
100:仕様書無しさん
07/02/06 01:03:48
> 所定のブラウザはインストールしてください。
> セキュリティパッチが出たら即座に当ててください。
IE7にしたら、動かなくなりました
うぇｗｗｗｗうぇっｗｗｗｗ
101:仕様書無しさん
07/02/06 01:39:58
>>98貴重な意見ありがとう。
私自身は仕事は人生楽しむための物の一つだというように考えてます。それだけに仕事で体を壊してはしょうがないとも思っています。
３～半年に１度、納期が近いときに忙しくなり、それ以外は平均残業30時間程度とリクルートでは聞きました。週休２日制ですし、労働時間が極悪とか体壊したみたいな意見も聞きますがそこまで大変なのでしょうか？
残業なんかどの仕事していても付きまとうものって考えているんですが、でもココを見てるとそうゆうレベルでもないのか？と疑問に思ってしまう。
専門出が使い古されるみたいな内容も気になります。実力社会だから関係無いのかと思っていたんですが、その辺どうなのでしょうか？
私のような考えの者がちょっとプログラミングに興味あった位で飛び込むと後悔してしまうのでしょうか‥
スレ違いかなと思いながらも、たまたま考えているのがＷＥＢ系なのでここに書き込ませてもらってます。マジな質問ですみません
102:仕様書無しさん
07/02/06 03:23:26
>>101
>専門出が使い古されるみたいな内容も気になります。
実力社会だから関係無いのかと思っていたんですが、その辺どうなのでしょうか？
98ではありませんが専門出とか大卒出とか関係なく
ＷＥＢ系もしんどいですし悪い言い方すると使い古される覚悟はしてた方がいいですよ
一度やってみたらどうですか？納期と労働時間で嫌と思えば辞めたらいいですから
まだ２２歳ですしそこら辺は先方も分かってますよ
103:仕様書無しさん
07/02/06 06:54:29
>>101
実力社会だけど、まず専門出って実力がないやつが多いよ。
ある程度できても視野が狭すぎるので、結局ある程度以上のびない。
いくら教えてもそういうことが理解できないやつがほとんど。
できるやつは、俺が色々仕込んで、転職させたりしてる。
そんな俺は人月２００万にフリーでようやくてが届きました。
それも一日四時間しか働いてません。かつ客からすると
コスト半分以下。
でも、こんな土方仕事は嫌だと思って、アメリカの博士課程に在籍中。
104:仕様書無しさん
07/02/06 09:00:13
すごいですね
105:103
07/02/06 09:48:55
全部ネタだったんだけど…
釣られてくれてありがとうｗ
106:仕様書無しさん
07/02/06 09:55:07
>97
ジャンルは違うが
URLﾘﾝｸ(s03.2log.net)
とか読んでみるといいかもしれない
運が悪かったらこんな現場に当たるかもよ
107:仕様書無しさん
07/02/06 09:57:14
専門出で現場未経験、２２歳いきなりＳＥならそのプロジェクトに参加したくない
と思うのは俺だけか
108:仕様書無しさん
07/02/06 10:43:24
>>105
さすが専門卒だけ会って、人のレス番でなりすましますね。
嫉妬？
109:仕様書無しさん
07/02/06 14:47:54
貼っときます
680 ：仕様書無しさん [sage] ：2007/02/01(木) 20:12:27
「ビスタ」、一部ネットバンキングで利用できず
URLﾘﾝｸ(www.yomiuri.co.jp)
流石はMS。
681 ：仕様書無しさん [sage] ：2007/02/01(木) 21:07:18
>>680
韓国ではもっと大変らしいよ。韓国のネットバンキングは ActiveX
使ったのばかりで、そのプログラムが XP までにしか対応していないのが
多くて Vista 使うとほとんどのネットバンキングできないんだって。
やはり一つのプラットホームでしか動かない凝ったものばかり作っては
いけませんな。
682 ：仕様書無しさん [sage] ：2007/02/01(木) 21:21:33
チョンなんぞどうでもいい
110:仕様書無しさん
07/02/06 14:52:51
683 ：仕様書無しさん [sage] ：2007/02/02(金) 07:50:21
β→RCとそれなりに時間があったのに何で誰も対応していなかったのでしょう？
M＄が対処を約束しつつばっくれた、なんてことはありませんよね？
単に銀行側がマに対応を指示しなかっただけ？
684 ：仕様書無しさん [sage] ：2007/02/02(金) 10:48:42
>>681
ActiveX ならそーゆー事もあるかも試練。
だが何で、そんなん使ってないみずほとかまで
動かなくなるんだろ。
MSが阿呆なのか、Web屋が所詮そんなもんなのか。
685 ：仕様書無しさん [sage] ：2007/02/02(金) 17:20:45
難しいことやりすぎてんじゃないか?
もっとシンプルにSSLで暗号化だけして画面凝らなきゃいいのに。
111:仕様書無しさん
07/02/08 00:18:27
俺は発狂。
ダークサイドに走った。
$ cat index.php
<?php
require_once('dl_local.php');
dl_local('project.so');
exit(project_main($_REQUEST));
?>
99.95%をCで書いた。
多分、誰もメンテできない。
おかげでZend Engineに詳しくなったぜ。
もう触る事は無いだろうけどｗ
俺は組込に帰る！！
112:仕様書無しさん
07/02/08 09:53:44
ApacheModuleのみで構成しました。
誰も付いて来れません・・・
113:仕様書無しさん
07/02/08 20:57:14
今考えると 16bitのWindowsでOLE2とかの時点で基地外じみたことやってたわけ
だから、なんで Ajax で OpenSource の Linux デスクトップに行きたいの？とか
言ってもはじまらないのかも知れん。WindowsVistaを割高に感じれば感じるほど、
「Windowsを使わない」方向へ圧力がかかり、Linuxでデスクトップに行くにはWeb
上に世界を作るのが実は最速だったりする。もともとWindows自体が「みんなで
渡れば怖くない」ということで広まったわけだから。
114:仕様書無しさん
07/02/09 13:58:14
そうでもないよ
115:仕様書無しさん
07/02/09 14:48:22
うん、そうでもない。
116:仕様書無しさん
07/02/09 16:11:23
トラックバック:ｽﾚﾘﾝｸ(tech板)
117:仕様書無しさん
07/02/09 23:39:29
>>113
Linux厨の妄想か……
わざわざ「デスクトップに行く」のに「Web上に世界を作るのが実は最速」なら
そんな糞ウザイLinuxなんか、誰がやるかっつーのｗ
> 「Windowsを使わない」方向へ圧力がかかり
Linux厨の願望か……
もうLinuxはWindowsに完全敗北したんだよ
いいかげん認めたら？
118:仕様書無しさん
07/02/09 23:41:18
a
119:仕様書無しさん
07/02/09 23:43:44
ヲタうざい。
120:仕様書無しさん
07/02/10 00:08:09
最近、VMWare上でLinuxを動かしてその上で開発を進めてるんだが、
コンソールではそれほど不便を感じないんだが
GUIでのマウスの加速度のかかり具合とか、
ウインドウの移動やソフト毎の他国語対応状況とか、
普段全然気にしてなかった事が気になって仕方が無いのがすんげー意外だった。
マウスの動きの微妙な違いがほんとにストレスになる！
121:仕様書無しさん
07/02/10 00:14:07
慣れろ
警告ダイアログ乱射のVistaに比べればその程度屁でもない
122:仕様書無しさん
07/02/10 01:13:26
漏れもVMware+Linux使ってるけどマウスはそれは慣れだ罠。
123:仕様書無しさん
07/02/10 09:14:06
なんだよ、SWFプログラマには細かい動きの注文つけるくせに
自分の使うPCのマウスの挙動には無頓着なのかよ
124:仕様書無しさん
07/02/10 21:30:35
関係ないけど、UNIX厨ってWEBアプリを肯定する奴が多いような気がする
125:仕様書無しさん
07/02/10 22:08:03
修正終わったぁああああ！！
誰だよ、こんなクソプログラム設計したの。
なんで個人情報のhtmlファイルが堂々とルート以下にあるんだよ。
Googleに引っかかってるじゃねーかよおおおお！
俺作ったわけじゃねーのにすげー怒られたぞおおお！！！
126:仕様書無しさん
07/02/11 11:23:39
>>124
育ちと環境の違いじゃね。
VB厨というかWindows厨はGUI歴が長い人種は見た目の些細な事につっこむけど、
UNIX厨は本質的なところは拘るけど、些細な見た目は気にしないタイプ
多いんだろ。
漏れもどっちかと言えば見た目の些細なところは気にしないクチだな。
127:仕様書無しさん
07/02/11 16:13:21
>>126
両方に共通するのは見た目も本質も気にしない奴の方が多いって事だな。
128:仕様書無しさん
07/02/11 23:44:56
本質ｗ
129:仕様書無しさん
07/02/12 00:38:47
>>126
> VB厨というかWindows厨はGUI歴が長い人種は見た目の些細な事につっこむけど、
> UNIX厨は本質的なところは拘るけど、些細な見た目は気にしないタイプ
ズレてるね。
GUI歴が長い人種は、従来のRADアプリケーションと比べての、WEBアプリのGUI開発の
メンドクササや汚さを良く知っているから、WEBアプリを嫌うんだろ。
対してUNIX厨は、マイクロソフトに対抗できるものなら何でも支持したがるから
マイクロソフトが主流じゃないWEBアプリを肯定したがるんだろ。
130:仕様書無しさん
07/02/12 11:44:37
漏れは昔のGUI開発とかした事ないクチでCUIばっかな人だったけど、
ここ２・３年だとフレームワークとかライブラリが豊富だから、
GUI開発の方がCUI開発よりも楽に感じるけどなぁ。
CUIで80x24の画面で画面遷移でファンクションキーで飛びまくりな
状況よりもWebの方が自由度が高く楽に実装できて、
作る側としてもありがたいんだが。
漏れはUNIX厨かどうか微妙だがマイクロソフトのエクセルは
すばらしいツールだと思う。
131:仕様書無しさん
07/02/12 11:56:24
GUIの方がサイズを変えたり、別ウィンドウを出したり、
マイルーチンが充実してくれば楽になってくるが、
不便なCUIで工夫していろいろやる楽しさから抜け出せん。
132:仕様書無しさん
07/02/12 11:58:12
あんたの考えているＧＵＩのレベルは低すぎｗ
133:仕様書無しさん
07/02/12 14:06:12
悪かったなｗ
134:仕様書無しさん
07/02/12 14:08:46
>>131
>GUIの方がサイズを変えたり、別ウィンドウを出したり、
確かAS/400+5250端末系だとCUI環境でも出来る。
135:仕様書無しさん
07/02/12 19:23:04
さすがにAS/400(CL+RPG)はソフトウェアの資産は莫大すぎるほどあるんだろうけど、
うるう年の計算や月末日の計算を自前or他人のサブルーチンで代用しなきゃいけない
点が微妙なモノがあるな・・・。
まー、あの文化は凄いし、安定性に関してはそこらの蔵鯖を凌駕しているけど、
作る側としては、あんま好きじゃないんだよな。
特に画面表示・更新のサブファイルの実装は素直にクソだろ。
ひたすら鬼の様なデータエントリー業務だと普通に5250のCUIの方がいいだろう。
136:仕様書無しさん
07/02/13 02:33:43
ジョエルが「Webアプリはパッケージソフト同等だ、業務ソフトだと思うな。」と言ってるよね。
営業には通らない話だが。
137:仕様書無しさん
07/02/13 08:04:16
ここで槍玉にあがるWebアプリってのはインターナルソフトウェアの話だろ？
Joelが言ってるのはYahooみたいなどんなユーザーが使うかわからんサイト。
>136のとこの営業がとってくる仕事はどっち？
5つの世界
URLﾘﾝｸ(local.joelonsoftware.com)
138:仕様書無しさん
07/02/14 23:37:03
現実に企業に納品するWEBアプリはクライアントアプリのように使われているわけだ
ここのスレで議論されているのはほぼそれじゃぁないのか？
つうか、ちょっとでも会社でソフト書いてたらこんなことくらいあたりまえだと思う
偉い人がいくらYAHOOが本当のWEBアプリとかのたもうても日本での現実は違うだろ
139:仕様書無しさん
07/02/15 02:24:17
>>133
怒るな。
低水準のアプリケーションを組めるってのは凄いんだぞ。
アセンブラみたいに。
140:仕様書無しさん
07/02/15 02:25:59
何か違うと思うな
141:仕様書無しさん
07/02/15 23:14:09
JavaScriptの単体テストはめんどくさい。
しかもオブジェクトが１個の時と複数の時で扱いが違うから
ちゃんと単体しないと思わぬバグを残してしまう・・・
あ～、やだやだ
142:仕様書無しさん
07/02/16 23:37:55
各ブラウザの各バージョンでのJavaScriptのテストなんてやりたくねぇ。ってかしねぇ。
143:仕様書無しさん
07/02/17 00:13:37
jsにもhtmlみたいな文法チェックがあるといいんだけどな。
144:仕様書無しさん
07/02/17 10:30:44
そんなことしたら
デザイナがjs書けないだろｗ
145:仕様書無しさん
07/02/17 23:43:02
俺、某商社の子会社に常駐してんだけどユーザーがあほで困っています。
昨日打ち合わせがあったんだけど、今エクセルで配布計算をしているのをＡＳＰにしたいらしんだけど、何個かシステムの案をあげてくれとかいってきた
具体的に仕様いわないと分からないだろうがって感じ
しかも昨日今エクセルでテーブルを１つしか使ってないのをどういう構成でいきますかとＱＡあげたのに放置だし
マジムカつく
146:仕様書無しさん
07/02/18 00:03:11
ユーザはアホです
アホにも分かるように説明し金をむしりとるのがプロです
147:仕様書無しさん
07/02/18 00:07:57
曖昧な仕様の時はドリームぶちまけとけ。
一番やばいドリームが採用されたら逃げろ。
148:仕様書無しさん
07/02/18 00:09:43
>>145
ユーザはアホなものだ。そのアホをなんとかするためにSEがいるのだ。
そのユーザの最大の問題点はSEではなくマのお前に相談したことだ。
マじゃなくてSE(または営業)に相談するように言っとけ。
149:仕様書無しさん
07/02/18 00:41:29
前スレの422みたいな子だな
150:仕様書無しさん
07/02/18 01:45:01
ユーザーにテーブル構成とかはどんな感じにするのか聞いても無視だぜ
アホというより人としてどうよ
そのユーザーにマスタは物理削除にしますかそれとも論理削除にしますかとＱＡ出しても放置ってどうよ
151:仕様書無しさん
07/02/18 03:44:11
>>149
なんか、気になったから過去ｽﾚ見直して「ああ、なるほど」と思った。
おまい、マにあるまじき記憶力の良さだな。
152:仕様書無しさん
07/02/18 06:11:51
確かにそういうユーザーは困るよね
仕様を抽象的にしか言ってこない奴
153:仕様書無しさん
07/02/18 08:21:53
仕様を具体的に言えるんだったらSEなんて全員要らないだろ
154:仕様書無しさん
07/02/18 09:48:04
ユーザーが仕様を抽象的にしか言わないのは当たり前。
それを具体的な仕様に起こすのもこちらの仕事でしょう。
155:仕様書無しさん
07/02/18 10:28:57
漏れも>>154の意見に賛成だな。
漏れが上司だったら>>145みたいなアホは客先には出させずに
一生底辺PGで社内にひきこもっていただくけどな。
156:仕様書無しさん
07/02/18 10:37:58
確かにそういうユーザーは困るよね
仕様を抽象的にしか言ってこない奴
157:仕様書無しさん
07/02/18 10:43:10
ユーザーなら仕方ないだろ。
仕様を抽象的に言うSEなら死ねって思うけど。
「だから、ここら辺でグリグリってやると
この辺にいろいろな情報がスパーンって表示されるんですよ。」
みたいなやつ。
158:仕様書無しさん
07/02/18 11:10:35
長島監督乙
159:仕様書無しさん
07/02/18 12:11:07
問題は，
確かにそういうSEは困るよね
仕様を抽象的にしか言ってこない奴
みたいなのが多くて，結局，末端のPGにしわ寄せが来ることが多い，
ってことではないかと．
160:仕様書無しさん
07/02/18 12:15:22
>>157
長島さんがSEならこの業界どうなっているのやら
161:仕様書無しさん
07/02/18 12:16:42
>>160
みんなのびのびできて却っていい業界になってたかも
162:仕様書無しさん
07/02/18 12:35:42
>>161
本人はプラス思考だが、野球に関してはとても厳しい人だぞ
163:仕様書無しさん
07/02/18 13:19:49
つか「ユーザーが仕様を抽象的に」の時点でおかしいだろ。
ドリームを吐くのがユーザーもしくは営業
仕様を決めるのはSEなのに、
ユーザーが仕様を言うワケがない。
>>145がSEなら無能だし、PGだったら妄想乙だな。
164:仕様書無しさん
07/02/18 13:46:12
>>145
今の少ない情報から、出せる案を出すのがプロじゃね。
「ちょっと情報が不足している為、細かい部分についてはこれからつめていく、
という形になりますが・・・」と
>>145の常駐先での位置づけ、
ユーザ会社（商社）内でも依頼を出してくる奴の位置づけ、
などが分からないからどこまで理不尽な指示なのか分からんけどね。
165:仕様書無しさん
07/02/18 15:14:14
つーか、ユーザーはそもそも抽象的って言ってるやつは根本的に勘違いしてる
ユーザーが「ユーザー自身の業務内容の仕様を抽象的に」説明する事が問題なんだよ。
業務内容なんて、ユーザーしか知りえないのに抽象的に言われて分かるかって事だ。
だから、SEは第三者としてユーザーの語る仕様の曖昧さをはっきりさせて、
システムとして自動化できる領域を決定して設計する。
業務をはっきり伝えたうえで「ここを自動化したい、ここを自動化したい」という
ドリームをユーザーが語るのは当然だが、その前に業務仕様だけははっきりさせないければいけない。
これは、ユーザーにとっても義務。
業務内容の複雑さを後出しで追加されないようにSEは頑張る必要がある。
166:仕様書無しさん
07/02/18 15:23:11
使用変更は金がもうかるからなるべく設計はあいまいに
しておいてくれると助かる
167:仕様書無しさん
07/02/18 15:34:30
>>166
リリース前にその「仕変」を言い出したら
デスマにならんか？
168:仕様書無しさん
07/02/18 15:56:05
断れりゃいいんだけどね
169:仕様書無しさん
07/02/18 16:24:26
>>165
>ドリームをユーザーが語るのは当然だが、その前に業務仕様だけははっきりさせないければいけない。
>これは、ユーザーにとっても義務。
だから、ユーザーからそれをしっかり引き出すのがSヨの仕事だろっての
ユーザーなんてシステムに関しちゃシロートなんだからどこまで具体的に言えばいいのかわかってねーだろ
170:仕様書無しさん
07/02/18 17:30:22
>>169
そうじゃなくて165が言いたいのは
システム化対象になっているユーザの普段の業務を
具体的に言えといってるのに抽象的にしか表現できないってことだろ？
システムの機能やそのインプリはSEが考えるとして
こういうことを普段やってますと表現できないユーザは
アホでしかないじゃん
171:仕様書無しさん
07/02/18 17:44:46
＞俺、某商社の子会社に常駐
と言っている奴が普段の業務も知らんのでは、
何のために常駐しているのか？って気がしなくもないが。
アフォな営業がとってきた案件ならともかく、
一緒に仕事しているSEで「あいつの言っている事が抽象的」
なんてのたまうのは真性のアフォって感じだが。
172:仕様書無しさん
07/02/18 17:48:27
>>170
新人らしく張り切ってるのはわかるが
あまり間の抜けた発言はしないほうがいいぞ。
ユーザは業務に関しては一番よく知っている人間。
だが業務内容を客観的に要求として伝える技術は範囲外。
理路整然と仕様としても完璧なRFPがいきなりできたら
おまえのすることないだろ？
173:仕様書無しさん
07/02/18 18:18:46
>170
知っていることと、プログラムできるように説明することとは
全然違うことなんだが、何を言ってるんだろうね。
174:仕様書無しさん
07/02/18 18:35:54
普段やってる事をSEがヒアリングして分析してシステムに落とし込むのに、
普段やってる事を曖昧に説明されることを何で問題に感じないんだろうね。
175:仕様書無しさん
07/02/18 18:42:00
まずは適当に作って運用してみて直していけばええやん。
細かいこと気にスンナよ
176:仕様書無しさん
07/02/18 18:42:02
>>145の自作自演がはじまりますたw
177:仕様書無しさん
07/02/18 18:47:10
＞知っていることと、プログラムできるように説明することとは
＞全然違うことなんだが、何を言ってるんだろうね。
SEがこんな寝言をホザいたらｿｯｺｰでクビになると思うが。
顧客とコミュニケーションとって仕様を固めるのが仕事だろうに。
178:仕様書無しさん
07/02/18 18:48:48
>>174
うわー、これは。
179:仕様書無しさん
07/02/18 19:16:00
なんか流し読みだけど、
ユーザーに業務内容を詳しく聞いてるのに
ユーザーは長嶋監督だから詳しく聞くのに限界があって
適当に作業してたらあとで長嶋監督にこってり絞られるから
やってらんねー。
という話を誰かが力説してるという構図ですか？
180:仕様書無しさん
07/02/18 19:47:20
>適当に作業してたらあとで長嶋監督にこってり絞られるから
これはないみたいよ。
181:仕様書無しさん
07/02/18 20:37:50
>>179
ユーザが全部の業務の流れしらなきゃ
だれが業務の流れしってんだよ。
一生デスマじゃねぇか
182:仕様書無しさん
07/02/18 20:44:26
>>181
確かにw
むしろ最初からユーザーがデスマってるか
183:仕様書無しさん
07/02/18 20:53:50
ユーザーは仕事の流れを知っているけど
アフォな底辺PGが理解できないだけって希ガス
184:仕様書無しさん
07/02/18 21:15:33
説明できないユーザがアホなケースと
説明されても理解できないSEがアホなケースの2種類がある
おそらく両方だと思われ
185:仕様書無しさん
07/02/18 21:38:58
ユーザで
A,B,C,D,E・・・
という作業を毎回するけど、実はCとEはなくてもいいんだよね、
という事は把握してない奴はいる。
そういう意味で業務はなりたってるけどシステム的に整合性？がとれてるかっていうと、
という会社は確かにある。
でもそこを、ヒヤリングした内容からシステマティックに資料／仕様化して
「今までのヒヤリング結果から、業務内容はA,B,Dのようになります。
これに対して認識違い、その他ありましたらご指摘願えますでしょうか？」
とユーザの合意を取り、「システム」を作り出すのはSEの仕事だ。
「ユーザがあいまいな事しか言わないからダメだ！」、って言うのはちょっとSEとしての力量不足かと。
186:仕様書無しさん
07/02/18 22:06:39
ユーザシステムの素人。
PGは業務の素人。
だからSEがいるんでしょ。
ユーザが厳密な仕様書かけたらSEいらないべ。
大変な作業ではあるけど、その部分が仕事なわけで。
187:仕様書無しさん
07/02/18 22:08:26
もうなんかwebアプリ関係ない話してるしｗ
188:仕様書無しさん
07/02/18 22:09:27
A、B、C、D、E、・・・っていう作業がありますと
説明できるユーザとできないユーザの話だろ？
189:仕様書無しさん
07/02/18 22:13:27
>>188
「え～と、月始めはこんなことやって～。。。月末はこんな感じ。
で、半期ごとにこんな感じ、だったっけ？どう山田？」
みたいなまったく整理されてないトークを聞きながら必死にシステム的にまとめていく
（議事録もそうだよな）
のがＳＥ作業です（以前はコンサル作業だったけど）。
190:仕様書無しさん
07/02/18 22:14:20
世の中デスマを誘発するなんちゃってSEって多いよな。
あれを減らすだけでもだいぶましだが
191:仕様書無しさん
07/02/18 22:55:19
>>188
そんな感じだと
ISO対応とかSOX対応なんか死にそうだな
192:仕様書無しさん
07/02/18 22:57:42
WEBソフトの話をしろよｗｗ
193:仕様書無しさん
07/02/18 23:19:19
「Webソフト」特有の問題じゃなくて、そこら中のプロジェクトで起こってる問題だから、
わざわざここで議論する必要も無かろうに。それとも、「Webソフト」の特徴的な何かが
こうした問題を引き起こしている、という方向で議論を展開していただけるのなら拝聴したい。
194:仕様書無しさん
07/02/19 00:41:57
アホなユーザーが担当のWEB開発はつらいのは認める
俺この前ASPで一覧の内容をCSV出力するプログラム作ったんだけどそのときユーザーがデータにカンマ入れやがってこれずれるよとかぬかシヤガッタ
195:仕様書無しさん
07/02/19 00:45:52
>>194はアホなの?
196:仕様書無しさん
07/02/19 00:48:32
>195
アホというか、おつむの可哀想なヒト
197:仕様書無しさん
07/02/19 00:48:31
>>194
つまらん
198:仕様書無しさん
07/02/19 00:48:39
俺は大人の対応でCSVの仕組みを説明しタブ区切りにしますかとＱＡを出したがその後返事が来ることはなかった
ユーザーって何様よ
199:仕様書無しさん
07/02/19 00:50:27
>>198
やめとけ。
200:仕様書無しさん
07/02/19 00:52:27
ユーザーに聞くのはおかしいべ
201:仕様書無しさん
07/02/19 00:54:39
んだな。
デリミタ位、自分で決めようよ。
202:仕様書無しさん
07/02/19 00:57:10
あいつら、自分を神だと思っているから我慢するほか無いよ。
203:仕様書無しさん
07/02/19 01:03:13
>>200
確かに
ユーザーはCSVって何？から始まるからなｗ
ＱＡ上げでもってなかなか帰ってこないのは仕方ないべ。
それを考えられないお前はＳＥしっかくだな。
204:仕様書無しさん
07/02/19 01:32:31
まー、CSVで出力させる際は、Excel対応形式のCSVでいいですか？
って言ってデータは " で括ってしまうのがいいと思うけどな。
205:仕様書無しさん
07/02/19 04:23:42
なぜかWebデザインまでやる羽目になるプログラマは多いと思うんだけど、
そんな奴のための書籍とかってある？
ほどほどのデザインができるようになればいいんだ。
206:仕様書無しさん
07/02/19 06:41:00
>>205
2chばっか見てないで普通のWebサイトを見れ
207:仕様書無しさん
07/02/19 07:43:08
今日もバカなユーザーと打ち合わせかと思うとイヤになる。
年収７００では割に合わんよ
208:仕様書無しさん
07/02/19 07:43:55
>>207
給料たけ～
でも割りあわないわけね
209:仕様書無しさん
07/02/19 08:13:45
合わない
ちょっと聞いてよ
210:仕様書無しさん
07/02/19 08:14:03
嫌です
211:仕様書無しさん
07/02/19 08:16:16
俺、今統合パッケのフロントをアイマで作るプロにいるんだけど
212:仕様書無しさん
07/02/19 08:19:48
>>210
おまいネタフリやめれ。
聞いてやれよ
213:仕様書無しさん
07/02/19 08:26:08
某総研が某銀行経由で●ゴム幹にヒアリング行ってたんだけど
最近実はとか話がでて
このプロジェクとは客が●ゴム幹ではなく某銀行のパッケ作ること言うてきてその第一次導入先が●ゴム幹だとぬかシヤガッタ
だから今まで●ゴム幹専用で設計したものを汎用設計せんとあかんことになっちまって
マジムカつかない？
214:仕様書無しさん
07/02/19 08:27:15
>>213
どこ向きに仕事してんだか？
215:仕様書無しさん
07/02/19 08:33:01
>>214
>>213は何を言っているか分かりますか？
216:仕様書無しさん
07/02/19 08:39:18
しかもそのプロは某統合パッケをアイマとか言うデータのパッケでフロントをぱっけで作るっつうやつ
217:仕様書無しさん
07/02/19 08:44:09
先月フィットギャップと要件定義やって今月プロを外注したのにやってられん
218:仕様書無しさん
07/02/19 08:45:52
そのくせＣＳＶが少しずれただけでほえるのはマジきっついわ
219:仕様書無しさん
07/02/19 08:50:35
すっきりした
ありがとう
さぁ仕事だ
220:仕様書無しさん
07/02/19 09:13:54
典型的な仕事できない人ですね
221:仕様書無しさん
07/02/19 09:42:20
CSVなんてもううんざりだ！！ 2.csv
222:仕様書無しさん
07/02/19 09:45:35
時代はXML
223:仕様書無しさん
07/02/19 11:18:57
>>194
データ中のカンマ、改行、"ぐらい対応しとけよ・・・
ちなみに
CSV カンマセパレーテッドボリューム？
TSV タブｒｙ）
224:仕様書無しさん
07/02/19 11:23:17
普通ODBCドライバで出力しない？CSVてｔ
225:仕様書無しさん
07/02/19 11:26:04
>>224
それやると重いはず。
読む方はもっと重い。
226:仕様書無しさん
07/02/19 11:29:42
重いっつってもたかだか業務アプリでしょ？
たいしたことないよ
227:仕様書無しさん
07/02/19 11:42:36
>>205
ノンデザイナーズデザインブック
知識の有る無しでどうにかなる部分を説明
228:仕様書無しさん
07/02/19 12:26:17
>212
こういうヤツは嫌だっつーても勝手に語り出すから問題ねぇ
229:仕様書無しさん
07/02/19 13:26:17
>>223
CSVをカンマ区切りで出力する、と決めたのは開発側のSEなんだろうから
その時に「データ内にカンマが入っていれば半角スペースにエスケープしますけどいいっすか?
だめならタブ区切りに変えますが」みたいな確認は機能仕様書とかでやるよな普通。
データにカンマが入る可能性を見落としていて、逆切れしてるようにしか見えないな。
230:仕様書無しさん
07/02/19 14:12:15
個人的には必要なさそうならデータ内の改行はあらかじめ対応しないことにする。
で、カンマ区切りよりタブ区切りにする。で、タブ文字はデータに使用できないこととする。
さらっとスクリプト書いてなんかしたいときとかに楽だからね。
もちろん必要性がある場合はちゃんとするけどｗ
231:仕様書無しさん
07/02/19 22:33:16
俺が嫌だっつうのは今猿の俺がプログラムレベルの話を客から聞かされることよ
カンマなんてどうでもよいべ
明日はカル●●の用件聞かなあかん
マジ行きたく成羽
232:仕様書無しさん
07/02/19 22:37:09
ODBCドライバってなによ
なんかのテストツール？
233:仕様書無しさん
07/02/19 22:41:58
なんかこのスレで愚痴ってる奴って本気で底辺なんだなー、って感じがするな。
234:仕様書無しさん
07/02/19 22:58:34
ODBCを知らないとは
235:仕様書無しさん
07/02/19 23:04:10
webアプリが底辺なんだけどね
236:仕様書無しさん
07/02/19 23:14:41
と思い込まないとやっていけない底辺プログラマでした
237:仕様書無しさん
07/02/19 23:15:52
>>205
地道に勉強しる。
俺だって色使いの基礎から、レイアウトまで、ひととおりやった。
が、変にマルチタスク化すると、
専門のデザイナーさんが多忙で、仕方なくあとで本格的にやってもらう前提で
「暫定で」作った俺流レイアウトがそのまま採用されて、公開なんてあったけど・・・・orz
238:仕様書無しさん
07/02/19 23:25:28
あるある。
開発「デザイナいないっすよ」
営業「てきとーでいいからひとまず作ってよ」
開発「とりあえず（デザイン以外は）終わりました」
営業「ここ、右寄せしてよ。あとバランス悪いからレイアウトここをこうして…」
俺はデザイナじゃねーからそんな作業させんなっつーの！
239:仕様書無しさん
07/02/19 23:33:28
昔はPGがぜんぶやってたんだよ。。。。
240:仕様書無しさん
07/02/19 23:46:50
>>1
だったら組み込みに鯉ｗこっちは人手不足
241:仕様書無しさん
07/02/20 00:12:01
>>194
>>198
>>213
>>216-219
>>231-232
君、ガッキー（前スレの422の子）じゃないの？
ASPとか言ってるし、文体もノリもレベルも自己中度も似てるし、
ずーっとageてるし、何から何までソックリだよｗ
君専用のスレ、俺がせっかく立ててあげたのに、来てくれなくて残念だったよｗ
>>240
ガッキー君を差し上げましょうｗ
242:仕様書無しさん
07/02/20 00:14:26
(ﾟ⊿ﾟ)ｲﾗﾈ
243:仕様書無しさん
07/02/20 07:42:41
今日は恵比寿のカル●●にいって一日中馬鹿ユーザーのヒアリング。
鬱になるな
244:仕様書無しさん
07/02/20 07:48:28
俺が知ってる言語はCOBOLとPL1と400とASPだけです
知っているといっても画面を作る程度ですがね
俺は今猿だからそれで十分なんよ
ＳＥになるとそうはいかんだろうがな
245:仕様書無しさん
07/02/20 12:47:07
それ全部を言語と申すのじゃな
246:仕様書無しさん
07/02/20 17:11:37
>>244
原文：俺は今猿だからそれで十分なんよ
読み：おれはいまさるだからそれでじゅうぶんなんよ
高崎山にお勤めですか？
247:仕様書無しさん
07/02/20 21:37:41
>>246
普通にコンサルだよ。お前なんかより断然上流ｗｗｗ
248:仕様書無しさん
07/02/20 22:03:26
わーすごーい
俺247みたいになりたいなあ
249:仕様書無しさん
07/02/20 22:55:27
PHPがDelphiだって？
250:仕様書無しさん
07/02/20 23:20:42
画面つくるだけならExcelで十分だろう。
言語を知っている必要すらない。
ただSEからは激しく嫌われるだろうけど。
251:仕様書無しさん
07/02/20 23:45:19
最近は画面作ることすらない
画面はＰやＳＥがﾂｸﾙﾓﾝﾀﾞﾛ
最近はヒアリングやぱらめーた設計とフィットギャップしかやらない
252:仕様書無しさん
07/02/20 23:49:26
やってる仕事が上流じゃなくてグチってル時点で・・・
まぁ、ガッキーがんばれ！
253:仕様書無しさん
07/02/21 00:16:02
なんか自称上流ってあたりが激しくｲﾀｲな・・・
しかも匿名掲示板で自慢話(?)かよ。
2xhよりも精神病のカウンセリング受けといたほうがいいぞ。
254:仕様書無しさん
07/02/21 00:20:54
いまだに上流＝エラいと思ってる時点で世間についていけてない
255:仕様書無しさん
07/02/21 02:05:03
GETでパラメータ引きずり回すのが嫌で、DBに保存したらアクセスの
度にレコードが増えるのが嫌で、sessionにしたらsession貼る前に後続
ページに直アクセスされて嫌で、もう嫌
そんな俺でも普段は上流工程=エライ人
256:仕様書無しさん
07/02/21 07:46:29
別に自慢してないんだけどな…
俺はプログラムは新人の頃コボルで帳票出すのを２、３本作って以来やったこと無いからよく知らないんでね
ただこれだけ思う
上流やらない人って何のためにこの業界来たのって
すでに用件が決まったものを゛ただ゛作るだけで何が楽しいのか純粋に教えて欲しいです
基本設計は俺にはできないな
要件が決まった後の力作業はドラクエのレベル９０辺りのレベル上げと同じ感じがするから
257:仕様書無しさん
07/02/21 07:54:01
★神の領域★
ヒアリングから要件定義
★越えられない壁★★パチンコ★
ＳＥの外部設計
★チンコ★
内部設計以降
258:仕様書無しさん
07/02/21 07:55:15
>>256
なんかお前さん、ウォーターフォールの現場しかやったことないな。
汎用ばっかり？
今の世はエンジニア主導でやってくのがだんだんメインになってきてるしなぁ。
仕様決定専業の人がいるようなデカイプロジェクトばかりじゃないし。
個人的には技術的に枯れた、そういうプロジェクトは面白くなかった。
やっぱり新しい技術の開発やら、でっかいプロジェクトを始める前の
プロトタイピングのフェーズに呼ばれるってのがエンジニアの腕のみせ
どころかなぁ。
お前さんがやってるやつのほうが、面白さがわからん。ある程度こなしてしまえば
ルーチン作業だよ、世の中でお前さんみたいにプログラムできないSEがやるような
のは。
お前さんがたがつかっているパッケージソフトの開発のほうがずっと面白いんだがなぁ。俺から見るとあんたが言ってる上流ってのと、流れ作業のコーディングに
大して違いが見えないんだが。
259:仕様書無しさん
07/02/21 08:00:53
営業が出来るだけ人柄も良くなく、プログラミングも出来ない人を配置するとしたらソコしかないのだろう
260:仕様書無しさん
07/02/21 09:59:18
>>256
もしかして古い人？
最近はそういうのははやらないが・・・
261:仕様書無しさん
07/02/21 10:20:37
どうやったらその要件を実装できるかわかってないのに
よくその要件でシステム作ります、と客に言えるな。
262:仕様書無しさん
07/02/21 10:29:41
こういうのが午前2時半スレの住人を生み出す原因なのかもな。
263:仕様書無しさん
07/02/21 11:08:57
5カ月で1000画面を構築した就職サイト
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
メンバーは十数人、しかも学生も混じってたんだとさ
264:仕様書無しさん
07/02/21 11:14:36
1000画面必要なの？
誰が使うの？
作るだけなら作れると思うけど、それ以前に頭使う部分があると思う。
265:仕様書無しさん
07/02/21 11:25:30
>>263
おれが今月で２００画面くらい作ってるから、
単純計算だと１人でいけるな。。。
五ヶ月で十数人で１０００画面て少ないよな？
266:仕様書無しさん
07/02/21 11:37:47
>>264
表に出る部分だけでなく裏で使う管理画面とかも含めると普通にいくよ。
下手すると管理系画面が7割とかいうこともある。
まあ実際はWEBプログラムも構造化が進んでいるから、
実際に1000画面分コーディングするようなアホな会社はないと思うが。
モックはそういうわけにいかないから1000画面分作るけど。
267:仕様書無しさん
07/02/21 11:42:56
読むと、設計・ツール都合で1000画面だよね。
要求が1000じゃなく、その要求をツール使う都合で1000画面で作りましたって。
それって何かおかしくないか？
メンテナンス性とか。
268:仕様書無しさん
07/02/21 12:03:20
具体的に。
269:仕様書無しさん
07/02/21 13:37:30
>>263
> カットオーバー時は「自然に拍手が沸き起こった。
> 東京では互いに手を握り，会津では開発チーム・リーダーの胴上げまで起きた」
こういう反応が自然に出るって事はどうなんだろ？
うまくいけばいいけど、しくじった時はどうなっちゃうんだろうね？
そりゃメンタルも壊れるわ。
270:仕様書無しさん
07/02/21 14:35:55
Delphi for PHP
URLﾘﾝｸ(www.codegear.com)
が実用的な出来だったら、>>263 のやり方が普通になっちゃうのかもな
271:仕様書無しさん
07/02/21 15:13:51
.netならもっと速くできるのに
272:仕様書無しさん
07/02/21 15:56:19
1画面1画面がgmailみたいなjs使いまくりの画面だったらすげえって思うけど
どうせでっかい画像とflash、検索ボックスとリンクがあるくらいだろ？
273:仕様書無しさん
07/02/21 22:03:11
DBのレコードが1000件あって詳細ページを表示するだけで
1000件にカウントするとかそんなんじゃないだろうな。
つーか、Webで1サイト1000画面って大手ポータルじゃなけりゃ無駄な気しかしねぇ。
274:仕様書無しさん
07/02/21 22:12:57
もっと整理しろよって思う
275:仕様書無しさん
07/02/21 22:27:15
その1000はどう数えたのよ、って話になるわな、当然。
でもさ、これって肝心なのは
｢作るのは学生でもいい｣
っつヒキだよな絶対。S2DaoだのGoyaだのはダシにしてるだけだろ。
276:仕様書無しさん
07/02/21 22:38:36
>>273
ﾜﾛﾀ。
どこまで作りこんでいるのかしらないが、
普通に考えたら
・俗にいうユーザー画面（表に出てくる画面）
・運営会社のマスター画面（掲載管理など）
・営業マン向け管理画面（営業マンの補助）
・制作者用画面（原稿制作をする画面、まさか手でシコシコ原稿書いてるわけじゃないだろ。）
・求人会社用管理画面
はあるはず。
ユーザ向け画面+これだけの管理画面が必要になる。
場合によっては、経理システム用画面とかがあるかもしれん。
規模にもよるが1000行く可能性はあるかもな。
大手ポータルだと1000じゃ全然足らんよ。
277:仕様書無しさん
07/02/21 22:58:44
>>大手ポータルだと1000じゃ全然足らんよ。
そうだけど、この事例での1000画面は単なる画面じゃね？
278:276
07/02/21 23:02:34
といわれても、あくまでも一般論的な話で、
このサイトがどこまでやってるか知らんしなあ・・・
279:仕様書無しさん
07/02/21 23:08:07
>>256
>すでに用件が決まったものを゛ただ゛作るだけで何が楽しいのか純粋に教えて欲しいです
それが楽しいか否かは本人の資質によるところが大きいけど・・・
とりあえず、C++ コンパイラの１本でも書いてみたら？
処理自体の流れも、コボルで帳票出すのと似ているしね。
(入力 -> 変換 -> 出力)
また、完璧な要求定義書があるのは知っているだろ？
あんな厳密な要求定義、>>256 は書いたことある？
ま、あそこまで丁寧に要求定義がされていたら、
ドラクエのレベル９０辺りのレベル上げなんかとは
比較にならないぐらい単調な作業かもしれないけどさ・・・
280:仕様書無しさん
07/02/21 23:12:13
その1000ページを誰がどう見るのよが
この手の話うさんくさいしね
281:仕様書無しさん
07/02/21 23:17:59
>>完璧な要求定義書
それは見てみたい、ぜひ。
282:仕様書無しさん
07/02/21 23:27:30
>>281
JIS X 3014
これ以上厳密に書かれた要求定義書を見たことがあるなら、
是非教えてもらいたい。
283:仕様書無しさん
07/02/21 23:37:12
>>282
それでいいなら誰も現場で苦労しないよ...
だからモノ知らずだって。実際C++どころかBasicも実装したことないでしょ？
284:仕様書無しさん
07/02/21 23:44:00
>>283
>それでいいなら誰も現場で苦労しないよ...
その論理にしたがえば、
通常の職場ではこれ以上の品質の要求定義書が
書かれていることになるんだけど・・・
285:仕様書無しさん
07/02/21 23:59:59
>>282
そりゃシステムだけだったらな。
286:仕様書無しさん
07/02/22 00:04:29
だから、厳密な仕様書とやらがどう実装されてるか
｢検証するのは誰？｣
という視点がまるかた無いねぇ
287:仕様書無しさん
07/02/22 01:28:32
>>256
要件、って細かいところまで全部つめてるわけじゃないじゃないですか。
実現不可能に近い要件を自分の知識とネットその他の情報を
フル動員してなんとか実現させる、ちょっとしたパズル感覚、
そんな所に下流工程（皇帝って言ってもいいかな）のおもしろさはあるよ。
下からすれば上なんて、実際何ができるかを全く知らない人が
よく口八丁手八丁で仕事受けてくるよな、って思ってる。
上も下も経験してみれば、おもしろさもあり苦しさもある世界。
ただ、この世界で歳とってもやっていこうと思うと・・・
288:仕様書無しさん
07/02/22 07:50:14
>>286
そもそも >>256 の主張自体に、
そんな視点はまったくないのだが・・・
それに、言語処理系の検定ツールも
世の中には沢山出回っているだろ？
>>>256
>要求定義さえ済んでしまえば、後は単調作業
という主張を検証するには、「言語処理系の設計・実装」
というお題はピッタリだよ。
まさに必要十分な「要求定義」が存在する。
289:仕様書無しさん
07/02/22 09:43:51
元記事よく読めよ。
ツール使ってそのケース全てが１：１で画面になるってことだろ？
例えば一覧出して、データ追加して、確認して、修正して・・・・。
普通なら共通化する画面も、ケースが違えばツールが別画面で出力するから別カウント。
一覧画面、追加画面、確認画面、修正画面、承認画面・・・・。
290:仕様書無しさん
07/02/22 12:21:24
求人サイト系はシステムが入り組んでるから画面は多くなるぉ。
いろんな検索方法があったり、求人側と求職側に管理者側の画面も作らなきゃいけないし、
さらに特集記事なんかがあったりして、スペシャルコンテンツとか、スクール案内もあったりする。
291:仕様書無しさん
07/02/22 12:40:12
それを抽象化せずに全部作りましたっていったら、普通は屑設計とぼったくりって言うんだと思うんだが。
292:仕様書無しさん
07/02/22 14:11:38
そんなの絶対メンテしたくねえ。
293:仕様書無しさん
07/02/22 14:16:32
極稀にあるからな。
遷移元が違うだけとか一項目違うだけとかで、仕様書もロジックも丸ごと別画面になっているのが。
そういうのはkill file行きにしてる。最近だとデスノート？
294:仕様書無しさん
07/02/22 14:21:44
>>289
あれ、でもstrutsつかってspringつかってってやってくとさ
ロジック周りはほぼサービス層に入れちゃう＋ライブラリつくったり
継承したりするから、結局struts側では画面と１－１対応にして、
(FormとAction)終わっちゃわない？
295:仕様書無しさん
07/02/22 14:57:31
あーstrutsだと似たような画面を大量生成しやすいな
悪い意味で
296:仕様書無しさん
07/02/22 15:50:14
>>295
でもさ、ロジック層分離してたら、別にactionとかfrom増えても
対して変わんなくない？
Actionなんってみんな２０行切るし、request.setAttributeじゃない？
297:仕様書無しさん
07/02/22 17:31:40
1画面でできることがものっすごい単純でやたら画面遷移の多いwebアプリっていうことだろ？
美しくないなー
298:仕様書無しさん
07/02/22 17:34:57
>>297
ajaxやるより楽で安全じゃない？
299:仕様書無しさん
07/02/22 18:31:40
安全って？
300:仕様書無しさん
07/02/23 08:39:57
無難って意味じゃないの？
301:仕様書無しさん
07/02/23 18:17:20
無能でもクビにならないってことだろ
302:仕様書無しさん
07/02/23 22:56:24
リクエストもトラフィックも多くなるのでは？
303:仕様書無しさん
07/02/28 10:55:07
位置やフォントを指定しまくりでブラウザやユーザーを置き去りにしたり限定してる美しくないWEBアプリはもう作りたくありません＞＜
304:仕様書無しさん
07/02/28 11:47:20
プロジェクタで画面を見せているときに
ブラウザで文字の拡大を選んでも変わらないwebアプリだな
305:仕様書無しさん
07/02/28 12:28:53
なんかVBのアプリより惨い現状だな。
DLL減るじゃなく、ブラウザ、スクリプト減る。
306:仕様書無しさん
07/03/06 03:17:01
ニコ動がDBトラブルでサービス開始延期だってよ
307:仕様書無しさん
07/03/06 12:34:05
そっかあれもwebアプリだなｗ
308:仕様書無しさん
07/03/06 13:06:42
>>306
何がとらぶってんだろうなｗ
309:仕様書無しさん
07/03/07 11:03:14
LAMP仕事ってさ
Cとかの低水準言語でLinuxのカスタマイズとかもやるの？
310:仕様書無しさん
07/03/07 11:27:49
やりっこないじゃん。
大手と専門以外で誰がOSに手を出すのよ。
311:仕様書無しさん
07/03/07 11:40:14
いやサーバーに使うOSのカスタマイズもwebアプリ構築の仕事にはいるんじゃね？
312:仕様書無しさん
07/03/07 12:00:21
金と時間が潤沢に有るならそれは正論だけど
やってられっかというのが持論
313:仕様書無しさん
07/03/07 12:05:54
だよね、普通に言われるLAMPの仕事なんて、開発には金が出ないのなんの。
見た目のデザインとかには言い値で出すくせに、中身はかつかつ。
314:仕様書無しさん
07/03/07 13:01:49
値段相応の機能とセキュリティーでいいじゃん
315:仕様書無しさん
07/03/07 15:10:58
カーネルチューニングの話と、カーネルソースハックの話で、
噛み合ってないように見えるが。
カーネルチューニングは普通にやるだろ。
316:仕様書無しさん
07/03/08 00:38:44
商用ソフトウェア以上の性能がでるっていっても
そこまで必要とするのかな？
317:仕様書無しさん
07/03/08 13:47:52
カーネルまではいいとは思うが、DBの知識が中途半端なWEBアプリ制作者が多いなあ。
318:仕様書無しさん
07/03/08 18:58:11
>>317
Vs2005とSQL鯖で WEBとDB 2つの鯖に分けたはいいが
偽装しらないので外部からWindows認証で接続できなくて困ってるSEみてワロタｗｗｗｗ
319:仕様書無しさん
07/03/08 19:15:35
あんまりマイクロソフトの製品はしらんのだけど、
Vs2005ってWebの鯖なのか？
そしてWebアプリでどうしてWindows認証が関係するんだ？
普通WebアプリとＤＢはODBCかJDBCかデータソースかそこらで接続すると思うんだが。
320:仕様書無しさん
07/03/08 19:20:44
>>319
あぁ、すまん
ASP.NETの事を指してたんだ
321:仕様書無しさん
07/03/08 20:32:12
カーネルチューニングする前にサーバー増やすぜ。
俺ら頭悪いJava屋だからなｗｗｗ
322:仕様書無しさん
07/03/08 22:36:59
そもそもカーネルチューニングってナニ？
APサーバーとかでメモリ使い切れる様にMaxClientsとか
RDBでメモリ使い切れる様にキャッシュやプールの設定はとかはするけど、
カーネルっていじってそんなに効果でるもんなの？
323:仕様書無しさん
07/03/08 23:34:04
チューニングするより
台数増やしてバランサ使った方が営業的にもいい希ガス
324:仕様書無しさん
07/03/09 02:48:57
install manualにparameterの積算方法が指示されている製品があるだろ。
ひどい奴だとkernel defalt値のままだとcoredumpしたりpanicしたり。w
使い切るって言うのも違和感あるなあ。
変な読み方をすれば、導入時からswap使いまくりでdiskごりごりって感じにも読めなくもない。w
325:322
07/03/09 18:51:04
>>324
＞変な読み方をすれば、導入時からswap使いまくりでdiskごりごりって感じにも読めなくもない。w
んなわけねーよ。ｗ
PCで動くDB2なんかはどんなヘボい鯖でも動く様最小限の資源しか使わん様に
初期設定されてるから、メインメモリにあわせて調整するんだよ。
ああ、AS400は楽でいいんだけどなぁ。
326:仕様書無しさん
07/03/09 20:39:49
そこら辺とか、今日びインストール時に自動で判定してくれって思うんだけどどうなんだろうな。
327:仕様書無しさん
07/03/09 22:06:37
ユーザの意図までは自動で判定できないだろうけど
mysqlのsmall,medium,large,hugeぐらいの選択肢があるとイイかも
328:仕様書無しさん
07/03/09 23:52:48
>>327
Oracleの場合はPoor,Huge,Oops! となっております。
329:仕様書無しさん
07/03/12 10:41:22
SQLServerは一応メインメモリ上限までの設定がデフォルト。
ただし、DBサイズ以上のメインメモリを持つことが推奨される。
もっともStandard以下は2GB以内という制限があるが。
330:仕様書無しさん
07/03/12 19:16:10
学歴差別
URLﾘﾝｸ(i-get.jp)
331:仕様書無しさん
07/03/12 19:40:11
>>329
なんじゃそりゃ。インメモリDB使うわけじゃあるまいしそんなにメモリ増設できるかよ
332:仕様書無しさん
07/03/14 09:49:22
今から導入するシステムならどんな零細システムでも2GBくらいメモリ積んでるの普通っしょ？
333:仕様書無しさん
07/03/14 10:33:44
んなこたーない
334:仕様書無しさん
07/03/14 10:42:53
そおいえば、前に鯖に「どれだけメモリつんだらいい」と聞かれて
「つめるだけ」と答えたらネタでなくマジでつめるだけつんだ鯖がやってきた。
悪いことしたと思った（ｗ
今その鯖はこじんまりとファイル鯖で活躍しています。
#内心は玄箱HGで十分だと思ってますた
335:仕様書無しさん
07/03/14 11:48:02
IAサーバだと鯖のサイジングは
見積もりやるだけ無駄な場合が多い。
必要最低SPECだしても、圧倒的にSPECが上の鯖が
ローエンドモデルになってるしｗｗｗ
336:仕様書無しさん
07/03/14 13:28:04
>>335
すまん・・・ちょっと頭悪いんで理解しづらい
もう少し判りやすくｗｗｗｗ
337:仕様書無しさん
07/03/14 22:21:52
日常の足を買おうとして、50ccの原チャで十分なのに、
車屋に飛び込んで最低1000cc～と言われるようなものでは？
NASで十分ってだけだろ。
338:仕様書無しさん
07/03/15 11:10:42
お前ら最近コード書いてますか？
339:仕様書無しさん
07/03/15 11:14:49
オープン系の人も結局カーネルハックもしないのか・・・・
340:仕様書無しさん
07/03/15 11:16:19
カーネル八苦ってなに？
341:仕様書無しさん
07/03/15 12:42:22
>>339
ちゃんとその分の予算と工期があればやるさｗｗｗ
342:仕様書無しさん
07/03/15 12:51:59
別にやってもいいけど、後任者の事考えると、その辺りはいじらねーんじゃね？
OSを基本でセットアップしたら、ネットワーク周りのインスコ手順書作って
引き継ぐってパターンだと思うし。
343:仕様書無しさん
07/03/16 18:18:30
昨今の急造Java厨どもに理解できるわけがない。
344:仕様書無しさん
07/03/16 18:22:35
別に昔からJavaやってたから出来るものでもないんだが。
345:仕様書無しさん
07/03/16 18:57:39
できるやつが敢えてJavaの仕事なんてやるとも思えないしな。
346:仕様書無しさん
07/03/16 19:23:38
今はどう考えてもJavaの仕事が多いんだが。
昔を考えると今ほど普及するとは思えんかったが…。
昔にJavaやってのならそれはそれで凄いと言うか…、まあ凄いな。
347:仕様書無しさん
07/03/16 19:27:27
仕事が多けりゃそれを使うヤツが良いってものではない。
っていうかスラム化する。
COBOLやVBと同じ道。
348:仕様書無しさん
07/03/16 19:31:00
C++を知れば知るほど
Javaって厨房むけだなーって思う
それでデスマが減ればいいんだけど
減らないのが不思議だ
349:仕様書無しさん
07/03/16 19:34:05
↑そんなことをわざわざ書き込むお前が不思議
350:仕様書無しさん
07/03/16 19:36:32
厨房向けだから普及すると思うんだが。
量の増加は質の低下と言うのは仕方ない。
C++みたいに挫折者大量生産言語だから
デスマがないってのも幻想だしな。
デスマと言語は関係ない。
不思議でもなんでもない。
煽るならもう少しマシな煽りを入れろ。
351:仕様書無しさん
07/03/17 02:19:27
うちらは効率を良くしてデスマーチを無くすために言語をつくったはずなのだが、
今の状況はいったいどういうことだ？
352:仕様書無しさん
07/03/17 02:24:56
>>351
言語ではどうにもならんほどマネージャが腐ってるだけだろ。
人間そのものを作り変えないと状況は変わらないと思うな。
353:仕様書無しさん
07/03/17 08:22:16
>>351
(バカの壁 * 開発規模)/開発言語・環境の進展 が昔と比べて減ってないから。
ちなみに、バカの壁を実際に読んだ人間にはわかっている話だが、
人月の神話などシステム開発本とバカの壁の主題は同じ。
354:仕様書無しさん
07/03/17 16:42:55
＞うちらは効率を良くしてデスマーチを無くすために言語をつくったはずなのだが、
この>>351の会社がrubyとかC#とかの言語をつくったのか？
355:仕様書無しさん
07/03/18 01:47:26
Webごときでカーネル云々の話になる時点で
設計とか鯖構成を考え直したほうがいいんじゃないの？
356:仕様書無しさん
07/03/18 02:53:28
>>355
なにこの糞レス。いくらなんでもひどすぎるだろ。
357:仕様書無しさん
07/03/18 13:10:38
カーネルファックってバイナリいじるの？
358:仕様書無しさん
07/03/18 13:27:25
オープン系のLAMP環境の開発ってあまりカーネル弄ることない？
Javaアプリの開発ばかりするわけか
359:仕様書無しさん
07/03/18 21:08:03
>>358
藻前は具体的にどうカーネル弄るんだ？
360:仕様書無しさん
07/03/19 09:18:41
まあ、>>355が正論だろ？
きちんと、通常に行えるチューンを行った上で、カーネルいじるんじゃないの？普通は。
馬鹿は大したことないテクを見せたがるからすぐ弄りたがるけどさ。
そもそもで、チューン目的だったら金かけてハードを上げたほうが安上がり。
361:仕様書無しさん
07/03/19 15:17:10
自分とこのアプリのチューンすら出来ないからよく考えもせずにカーネルいじるんだろ
そうして転げていくわけだ
362:仕様書無しさん
07/03/20 02:36:25
いいからWEBアプリなんて頬びちまえよｗｗｗｗｗ
363:仕様書無しさん
07/03/20 09:08:31
WEB+DBとか読んでカーネルハックｗとか喜んでるﾊﾞｶだけだろ
364:仕様書無しさん
07/03/20 09:13:17
おれもいじらんなあ。業務鯖に自作機持ち込むのと同じ感覚。
365:仕様書無しさん
07/03/20 09:48:36
>>363
つうか、あぁいう本読んで意味もわからず遠回りなやり方とかしたがる馬鹿がいるから困る
366:仕様書無しさん
07/03/20 10:46:09
>>351
言語の差異はシステム開発において微々たる物でしかない。
構造型からオブジェクト指向へのパラダイム変化はそれよりも大きい。もちろんそれは言語のサポートがあってのことだけど。
ここから先に行くにはまた別のパラダイム変化が必要なんじゃない？
MDAとかアスペクトとかにその片鱗が見えるけど十分解じゃないよね。
367:仕様書無しさん
07/03/21 00:18:20
>366
唐突になにをいいだすんだ君は
368:仕様書無しさん
07/03/21 04:36:59
>>366
知るかよｗｗｗｗｗｗｗｗｗ
じゃあ自分で考えろよ
369:仕様書無しさん
07/03/21 08:43:48
自分で考えると言うかサ
・十分な開発資金
・十分な開発期間
・適切な開発プラットフォームの選択
・人材の育成
これらの簡単で極々当たり前の事が出来ないからデスマになるんだよ。
そして組織の上の方の人間が、派遣やら別会社に案件丸投げやら
その場しのぎで目先の利益追求してるから、現場の人間が
デススパイラルに突入してるだな。
370:仕様書無しさん
07/03/21 14:14:26
>>369
おまえは社会主義の国で仕事してろ
371:仕様書無しさん
07/03/21 14:20:40
↑
当たり前の事が出来ないﾍﾀﾚ
372:仕様書無しさん
07/03/21 14:59:48
>>370
なんで全てが不足しているとわかっている国で仕事するんだ？
373:仕様書無しさん
07/03/21 16:42:48
>>369は社会主義
↓
社会主義国家ｵﾜﾀ
↓
>>369ｵﾜﾀ
と、いうことだろ。
374:仕様書無しさん
07/03/22 10:07:41
>>369
そんなものわかってんだよヴォケ
開発の現場に立った事あればそんな事は絶対に理想でしかないといえるはずだ
おまえはどうせPG気取りのNEETか、趣味のPGかなんかなんだろ？
いいからお前消えろよ 話にならんから
375:仕様書無しさん
07/03/22 11:59:59
>>374 そういう始皇帝氏も話にならんと思うがな
376:仕様書無しさん
07/03/22 16:27:03
>>375
日本語でおｋ
377:仕様書無しさん
07/03/22 18:44:12
>>374
でこういう現場の底辺ＰＧは根本的な問題から目をそらして
「カーネルチューン」とか「オブジェクト指向」とか「Webソフトは糞」
とか言って憂さ晴らしでつかｗ
それこそお話にならない学生気分のアマチュアだな。
378:仕様書無しさん
07/03/22 19:18:24
漏れは>>369の条件から人材の育成がダメで、ﾃﾒｴの給料が安い点（ｗ）を
除けば漏れ自身はデスマ回避しているよ。
漏れが営業やSEも兼任している性もあるが、ちゃんと説明して
開発期間とか、開発鯖とかフレームワークとかの見積もりと
普通にしてるからデスマを回避するのはそんなに夢物語でも
なんでもないと思うが。
プログラムしかやってなくて、仕事相手が機械ばかりって人間には
デスマ回避はむずかしいだろうなぁ。
379:仕様書無しさん
07/03/22 22:11:20
つうか、それこそ上司や客と喧嘩する勢いで納期とか仕様を調整しているが
とりあえずデスマっていうほどのデスマは特に今のところないな
まぁ、そんな大きすぎる案件がないからってのもあるけど、仕様に関してきっちり時間とるようにしてあるからいいのかもしれん
仕様変更があまりないようにしてるつもり
かなり元の使用詰めておけばあっても、大きな変更ってのもないし
つうか、あたりまえのことなんだけどな・・・
380:378
07/03/22 23:18:50
漏れはRDBと言うかそういう基礎的な部分はキッチリ詰めるけど
インターフェイスの部分はユルユルだなぁ。
と言うかどーせこの部分は客からクレームというか要望が追加・変更される
事が多いので、カッコいい言い方だとTDDな開発スタイル。ｗ
あんまり喧嘩するほどの勢いではないが、誘導する感じで
お互い納得できるように決めるけど。
あんまり寝言が激しい時は「それは次の開発の時にまとめてやりましょう。
しばらく運用してから、現場からの意見も取り入れますので」って感じかな。
実際、本番始まる前に思いついたような仕様変更は悪影響多いし。
酷いのだと「やっぱ最初のがよかった」とか言われるし。ｗ
381:仕様書無しさん
07/03/23 11:06:02
WEB系の場合は特に最近はユーザーインターフェイス、
ユーザビリティが特に重要視されてきてるから、
設計で特にユーザビリティのところをやるだけやって、構築は結局デスマってことが多いな。
オープン系やってたころはそんなこと全くなかったけど。
WEB系に移っての大きな違いはここかな。
確実に動けばいいというのならば比較的楽なんだけど、
最近のWEBサイトは雑誌並みのデザインセンスが求められるから、
純粋なオープン系あがりな人は結構あっぷあっぷしてる。
しかも最近はFLASH+DB連動とかでさらにセンスが求められているし。
382:仕様書無しさん
07/03/23 12:45:31
で？
別にそれは最近の話題じゃないし。
そういう結果AJAXが出てきてるわけだし。
デザイン凝るのにデザイナー付けない程度のシステムって矛盾してるね。
383:仕様書無しさん
07/03/23 12:56:07
むしろ印刷回り皆どうしてる？
ペーパーレスとかの現状もふまえて最近ＰＤＦで出力するようにしてるんだが
384:382
07/03/23 12:56:25
いまどきデザイナーやコピーライターなしで作られたWEBサイトなんてあるのか？
385:381
07/03/23 12:58:23
Janeがおかしくなってた。
>>384は381です。ｽﾏﾇ。
386:仕様書無しさん
07/03/23 12:59:04
>>384
小さい会社なんかはそういうもんじゃないか？
ＷＥＢデザイン専門とか外注に出す金も取れないし
387:仕様書無しさん
07/03/23 13:39:16
小さな会社に来る程度の仕事なんだから、それなりのものだろ？
デザインに金が掛かるということをきちんと客に説明するか、製造側がデザインを分離して、客にデザインさせる。
それも出来ずにだらだら受けてるとしたら、自分が馬鹿なだけ。
388:仕様書無しさん
07/03/23 13:51:44
それなりの仕事で生き残れる会社って、なんてぬるま湯？
小さい会社ほど必死に仕事してるんだろうが。世間知らずめ。
389:仕様書無しさん
07/03/23 13:56:21
必死ってのを勘違いしてる典型。
じゃあ、必死に無い才能と知識と技術で、客の満足するデザイン作ればいいじゃん。
コストが幾らかかるかしらねーけど。
390:仕様書無しさん
07/03/23 14:07:04
コスト計算できない人
391:仕様書無しさん
07/03/23 14:28:07
まぁNECとかの技術者が大した事ないのもぬるま湯なんだろうな
NECという名前だけでふっかけることが出来る
まぁ、それも一種の才能だが
392:仕様書無しさん
07/03/23 21:46:39
＞最近のWEBサイトは雑誌並みのデザインセンスが求められるから、
誰でも知っている超大手企業でも結構並なセンスのサイトは
結構あるけどな。
純粋なオープン系ってよー解らんが、商用のオープン系(IBM)だと
デザインのテンプレやプラグインが最初から豊富にあるので、
なんにも勉強していないプログラマーでもそこそこの見栄えのが出来るぞ。
393:仕様書無しさん
07/03/24 00:57:07
え？PGがデザインやるの？
うちみたいな零細企業でもねぇよ。
394:仕様書無しさん
07/03/24 01:53:42
>>393
俺のところは
SE＆PG＆デザイン
つまりだな・・・・
自分で案件打ち合わせして仕様書いて
デザインも考えてそれを打ち合わせして
Pg作ってテストは専門のやつに任せて
納品しに行って
保守は保守専用のやつに頼む
ちっちゃな案件はこんなかんじ
395:仕様書無しさん
07/03/24 05:40:26
マでもフツーにセンスある奴はある
専任デザイナーとかなんとか言いながら、センスがないのを自慢してるよーなもんだろ
396:仕様書無しさん
07/03/24 07:28:47
デザイナー不要論を掲げるワケでもないけど、
デザイン外注だとレスポンスが悪いのもあるんだけど、
Web開発はスピード命って面があるから、
なるたけ自社内で教育したり研修いかせたり
する方がメリットあると思うが。
人事まで考えるのは漏れらの仕事じゃないんだけど、
メンバーには色々な経験をさせた上でそれらを業務に
生かす方針の方がいいと思う。
人間固定業務ばっかやらせているとモチベーション下がるしな。
397:仕様書無しさん
07/03/24 11:44:34
>>394
ファミコンのゲーム開発みたい
398:仕様書無しさん
07/03/24 20:24:21
どんなにカッコいいこと言ってても
結局ケツを拭くのは
保守・運用部隊。
いつまでSQLPlusを使わせる積りだ。お前ら。
399:仕様書無しさん
07/03/24 21:14:42
>>398
漏れの中では保守・運用部隊は障害が起きたら「障害おきますた」
と連絡入れるだけで実際なんにもしなくて、
開発部隊に「ここでリターンキー」まで書いた手順書を貰わないと
対応できない、素人集団だったりするんだが。
キーボードを一本指打法で打ち込んでいる姿を見て逆に感動した覚えがある。ｗ
まあ、開発とかで壊れてしまった人間の行き着く果てだったりもするから
漏れらも彼らに対してはあんまり強くはいえんのだけどもな。
400:仕様書無しさん
07/03/24 21:49:31
一本指打法に吹きかけたｗｗｗｗｗ
今度使ってみようｗ
401:仕様書無しさん
07/03/25 08:50:43
>>399
たぶん開発のキミも欲しくなるような運用部隊だと思うよ：
SQLぐらいはふつーに書く。
営業からのアタマの悪い・手間ばかり掛かる質問や依頼もこちらで
一次請けして、開発部隊がなるべく開発に専念できるようにしている。
障害対応はさすがに無理だが、
手作業が必要な時はマンパワーを供給。
手順書とかはウチ作るけど、それは複数の人ができるようにしとく為。
どのみち開発の作った手順書はそのままでは使えない。開発には
メモ程度で済まして貰って、あとは何度か立会いしてもらう。
402:399
07/03/25 09:55:08
>>401
欲しいかどうかは微妙だよなぁ。
こういっちゃ失礼だけど、そりゃ障害とかなければ運用・保守って暇人だから
空いた時間で自己啓発で本読んだりしてSQL程度なんざ覚えたつもりになれるだろう。
あとウチは営業と開発は珍しく仲がいいから、あんまりその手の話題は気にならんけど。
開発で重要なのは小手先の技術や知識じゃなくて人の１０倍程度の体力とか
冷静な判断力とか、常識(w)だったりするから、あんまり知識自慢されても
開発部隊からすると「へー、すごいですねー（棒読み）」で終わるんですけど。ｗ
403:仕様書無しさん
07/03/25 11:06:24
>>402
>開発で重要なのは小手先の技術や知識じゃなくて人の１０倍程度の体力とか
>冷静な判断力とか、常識(w)だったりするから
技術と知識が体力や常識より下って・・・
404:仕様書無しさん
07/03/25 11:16:39
>>403
平たく言えば、24時間365日に対する高可用性、耐デスマ力、耐パニック力、耐低賃金力が重視される。
回避能力は二の次…。wwwwww
405:399
07/03/25 12:02:05
>>403
開発にどんな幻想を抱いているかは知らんが、やはり体が資本だぞ。ｗ
技術や知識は現場で教えられる、と言うか叩き込めるが、
体力や精神力がついてこなかったら意味がない。
そして常識はないと困るんだが、体ら精神が壊れると常識も
連動して壊れていくし、最初から常識がないとマトモな設計は出来ない。
小手先の技術よりも常識にそった実装という見極めが出来るのが
プロと趣味アマとの違いだろう。
そして常識があれば危機回避が出来る。
当たり前だが。
406:仕様書無しさん
07/03/25 15:23:22
>>404
最近のWebソフトってCOBOL屋が作るんだろうか?
407:仕様書無しさん
07/03/25 15:26:06
>>402
凄いですね。
それだったら運用も暇かも。全部お任せするわ。
これからも頑張ってください。
408:仕様書無しさん
07/03/25 16:06:39
たかが運用・保守が妙なプライドもって開発に食って掛かってもしゃーないと思うが。
実際運用なんて誰でもルーティンワークがほとんどなワケだし。
409:仕様書無しさん
07/03/25 16:07:35
ｽﾏｿ
「誰でもルーティンワーク」→「誰でも出来るルーティンワーク」
410:仕様書無しさん
07/03/25 16:48:59
「たかが運用・保守」か。開発よりよっぽど金になるのにな。勿体無い。
411:仕様書無しさん
07/03/25 17:12:22
○○より金になる、と言い出すとキリがないが。
そもそも開発は一番の貧乏クジだろう。ｗ
ただ開発の一線でやっているヤツはある意味、金なんてどーでもいい連中だろう。
根っこに「機械いじりが好きだから」って連中が半数ほどいて、
「新しい事やりたい」「こんどはこういう事覚えたい」って連中で
なければ勤まらんよ。
社交辞令でなくて死ぬまで勉強し、創る事がメインの職種だからな。
412:仕様書無しさん
07/03/25 17:14:13
だから開発の人間は頭おかしいと言われるのだなｗ
413:仕様書無しさん
07/03/25 18:29:48
なるほどなw
414:仕様書無しさん
07/03/25 20:02:49
一般職でもノイローゼやら欝の病気になる事はあるんだが、
開発なんかだと、マジで体とか精神とか壊れるのは珍しくない。
運用とかでも24H交代制とかなら体壊す話も聞かない事はないんだが、
開発のデスマに比べたらヌルいケース多いしな。
で、今はｴﾝｼﾞﾆｱに厳しい時代だからある程度たつと
半数以上が開発職から離れていくよ。
たぶんソレは正しくて、普通なんだと思う。
デスマ連チャンで奴隷モードで頭がおかしくなって永遠にコーダー＆テスター
状態ってヤツもいるんだけど、そんなヤツものプライドみたいなのはあるからな。
そういうヤツは「開発より金になる」と言われてもふーん、で終わりだろう。
開発とそれ以外の営業やら運用とは生きてる世界が違うのは事実だな。
415:仕様書無しさん
07/03/25 21:17:51
そーだなぁ、開発は研究・運用の奴らとは同じ技術の世界に
生きてるはずなんだけどやっぱり種類が違うと思うよ。
研究が現場を見ずに考えたクソ技術を嫌々ながら組み入れ、
運用に本当は回したくない不誠実なコードを納期のプレッシャーから組み込み
到底「これが私のコードです」と言えないものを提出すると言う
プライドを心底ズタズタにされる日々を送りながらも
なお開発の前線に立ちたいと言うことだからな。
結局は「Hello, World!」を忘れたくない気持ちなんだと思うぜ。
エンジニアに厳しい時代だろうがなんだろうが、プログラムが好きっていう奴ら。
俺は嫌いじゃないぜ。
416:仕様書無しさん
07/03/25 23:02:24
漏れもいつかは一線を退くんだろうけど、一般職になったら
ヌルい状態に逆に耐え切れるのか不安だしなぁ。
なんか脱サラして田舎で畑を耕す人の気持ちが解る気がする。
って戦争から帰ってきた兵士みたいなコメントだｗ
417:仕様書無しさん
07/03/26 13:23:12
俺が学んだこと開発業務のあるＩＴの職種はやばすぎる
418:仕様書無しさん
07/03/27 22:23:30
>>415
＞到底「これが私のコードです」と言えないものを提出すると言う
＞プライドを心底ズタズタにされる日々を送りながらも
＞なお開発の前線に立ちたいと言うことだからな。
ごめ、マジで泣けてきた・・・orz