今までみた絶望的なソースコード [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
今井氏：ソースコード公開は、社長のティム（*2）の意向です。彼はバリバリのプログラマーで、初期の「Unreal Engine 1」を
1人で書いた人ですが、若い時に雑誌に載っていたコードを書き写して勉強したそうです。それで今の若い人にも、プロのソー
コードとはこういうものだというのを見せたいという願いがあって、ソースコードを公開しています。本当に今のゲーム業界の
事情を憂いてる1人だと思います。（*2）Epic Gamesの創業者兼CEOであるTim Sweeney氏
出村氏：読みやすいコードですよ。「C++」というのは、黒魔術（高度な計算）が多くなりがちな言語ですが、
そういうこともなく、すっきりしていて目的の機能も探しやすい。解読しやすいコードなので、確かにお手本になると思います。
僕は初代のゲームボーイからプレイステーション 2の頃くらいまでゲームプログラマーだったのですが、ゲームプログラミングでは
必ず数学が出てきます。行列とか三角関数とか。もちろん今でもまったく不要になったわけではありませんが、そういう知識の
重要性は薄れてきていると思います。「Unreal Engine」では特にそうです。
http://game.watch.impress.co.jp/docs/interview/20150417_698349.html
初級者から中級者へ昇格する時期は、ほぼどのようなソースコードでも読める程度にプログラミング言語に精通し、
また偉いプログラマーの提唱したデザインパターンも一通り理解したくらいの時期である。
すると、プログラミング言語の持つあらゆる機能と、偉いプログラマーの提唱するあらゆる技術を使わねばならない
という思い込みが発生する。そしてHello Worldにまで崇高なオブジェクト指向や壮大なデザインパターンを
適用しようとしだすのである。
その結果、
* 大量のクラス
* 迷路のような変数渡し
* 底なしに深いネスト
などといった凄いものが生まれる。また、条件分岐に三項演算子を乱用するなどの症状も多く見受けられる。
最終的には第三者にとって読みにくい保守性の悪いスパゲッティコードが生成されることになる。
http://monobook.org/wiki/%E4%B8%AD%E7%B4%9A%E8%80%85%E7%97%85 クソコードとバージョン管理に直接の関係はない。
だが、バージョン管理を使えないような奴は
クソコードを書くというのは大体あっている。 >>484
CVSは25歳
SVNは15歳
Gitは10歳
バージョン管理ツールでやればいいな >>482
バージョン管理システムは手段であって、
本来はその改修モジュールの対応前、対応後のソース一式がまとまってれば文句はないんだよ。
対応後の一式があれば、それは次の対応前の一式だし。
そこをサボって1つのファイルに前後を入れるから意味がわからなくなる。 >>491
小さいアプリならそれでいいだろうけど、
複数人が開発している大きなアプリだと、
1. どうやって各自の変更をまとめるのか？
2. 改修は何百、何千となるが（少なくともバグの数と機能の数以上になる）、それだけの数の「一式」を欲しいのか？
それを実現してくれる手段がバージョン管理システム >>492
大規模開発してるけど、
各自の変更自体は、そもそもがバージョン管理システム以前の仕組みとして、
変更仕様書書いてスタンプリレーして台帳化までしてるので問題ない。
それだけの数の一式、と言えども、サブシステム毎には別れるし、その中でのモジュール毎にも別れる。
あるモジュールの、rev xとrev yは持っておく、って事だよ。
出荷は、モジュール単位でも出せるけど、基本はサブシステム毎で、さらに言えばパッケージ毎の定期出荷にのせるべきだな、うちは。
サブシステムA ver 1.1は
モジュール1 rev 1
モジュール2 rev 1.1
で出来てて、
パッケージ ver 1.2は
サブシステムA ver 1.1
サブシステムB ver 1
で出来てるって台帳がある。
実現は紙で1990年代から出来てる。
それを便利にするのがバージョン管理システム。
手段じゃない。道具。 >>493
では聞くが、
その台帳を検索するのに、どれだけの時間がかかるのか
考えたことはあるかね？
思い出すだろう？ 大量の台帳の山から
その時の情報を探すのに数日かけたことを。 >>493
ソフトウェア会社なのに、それをコンピュータで
実現してないってのがダメな所だよなｗ
自分の仕事も効率化出来ない（コンピュータ化できない）
会社に他社の仕事の効率化なんてできっこないわけさ。
それをコンピュータ化したのがバージョン管理ツールだからね。 >>494
> 楽したつもりで道具に使われてる奴等多すぎ
>>495
> 言っとくが楽してるつもりは一切ないからな
だよなｗ 同じことができる道具。それがあって、
楽できない道具を使うの（手動で管理ｗ）が偉い！って思っちゃう。
体育会系かよｗ エクセル使うとズル呼ばわりする老害と一緒だ。
同じ道具なら、より効率的に早く楽にできる方がいいじゃん？
バージョン管理ツール使えば、台帳なんかで情報を調べるだけじゃなく、
その時のソースコードに戻すこともまで簡単にできる。
一番重要な事をお忘れか？
最終的に九州から北海道まで歩いていけるから問題ない？
それだけでは全然足りない。どれだけの時間がかかるまで考えてこそプロ。 まあ、あれだよな。
使える形で保存されてないデータは、使われない。
使える形で保存されているならば、使われる。
使われないデータをたくさんためても
自己満足程度の意味しかないわけで。 >>498
それで新幹線と飛行機と船で行けたとして、
「着くのが早いから」って理由で飛行機に乗るのはいいと思うけど
「マイル貯めるために」とか「ボンバルディアの機材こそ至高」ってのは
なんだかなあ、って話っしょ
こういうのはその時にベターなもの使えばいいの >>500
例え話はわかった。具体的にはどういうことかって話だ。
バージョン管理を使わないと凄く非効率だから
殆どの場合はバージョン管理ツールを使う方がいい。
ただしバージョン管理を使えないという呆れるほど技術力が低くて
使えないものを大量に生成し多くの無駄に時間がかかって、あとで
自分らが苦しむだけなんだが、それを許容するのならば、
手動で管理しするのがベター（笑）ってことだよね。 >>490
VSSやCVSやSVNやら今使ってるの皆無だろ
以降の際に履歴捨ててるだろうし
標準化されない限り結局は短命
Gitも20年先使えてるかわからんしな >>496
>>497
何言ってるんだ…
実現自体は昔から出来ている、それを便利にするのがバージョン管理システム、と言っているだろ。うちでも使ってるよ。
台帳自体もそっから今は自動で作ってる。便利だよ。
2000年代前半は内製システムだったけど、今は普通にバージョン管理システムとチケットトラッキングシステムだよ。
そもそもリリースノートは台帳から作るからリリースノート見ればわかるし、
わからなくて台帳をなめて、それでもわからなくて、
各文書の山から検索しないとダメな事自体、発生したらヤバい。
同様に、台帳の表題をあやふやにしてると痛い目に遭う。
検索したらわかるっしょ、と適当にする奴居るけどね。
今でも、サーバ、ネットワーク全部落ちてもサポート程度は回る程度に台帳も文書も刷ってるよ。
お陰様で震災でもなんとかなった。 >>502
使ってないだけで、使える。
移行の際に履歴を切り捨てるのは、お前の問題であって、技術の問題ではない。
他に標準化されているものなどない。
紙の管理？ ソースコードのコメント？ どれも標準化されてない。
今のデファクトスタンダードがgit
Gitから移行することはあっても、Gitがなくならないことは
1982年（33年前）に登場したRCSがまだ使えることからも
歴史が証明してくれている。 >>504
うちはパッチ当ててでも使うだろうな。
多分デファクトスタンダードはあるけど、
デファクトスタンダードなんてどうでも良いと思うよ。
管理できれば良いんだから、無理に流行りに乗らなくても。
あと、gitはおそらく向いてないな。うちには。cloneに時間やたら掛かりそう。 > 管理できれば良いんだから、
だからまたｗ
管理できるのは最低限の条件で、
それを素早く確実にやるのがプロでしょ。
出来ればいいんでしょじゃないってｗ
> あと、gitはおそらく向いてないな。うちには。cloneに時間やたら掛かりそう。
ん？ cloneするのは最初の一回だし、ネットワークが遅いなら
特定のディレクトリからでもcloneできるが。 >>504
使ってないなら見てないんだから活用できてないわな
大きな修正にはバージョン管理は当然としてソースにも履歴を残してリスク軽減が当然だと思うんだけどな
そのバージョン管理のソフトも必要なときには使えなくなってる可能性を考えるべきよ
その履歴が標準化されてれば将来もコンバートできたりするんだろうがな
何かに過信してリスク分散もできない会社のシステムなんて怖くて使えないわ >>508
卑怯ですね。
バージョン管理ツールには、凄くいろんなことを求めて
それが出来ないと悪く言うくせに、
最初から何も出来ないものは、出来なくても文句言わないんですか？
> 何かに過信してリスク分散もできない会社のシステムなんて怖くて使えないわ
リスク管理っていうのはね。コストを考えなきゃだめなの。
ソースに履歴を残すことのデメリットを計算に入れてないから、
あんたの考え方は、考えるに値しないの。 >>507
何言ってるかわからん。
バージョン管理システムに反対してるつもりはない。使ってるし。
ソースにコメントで残す事を肯定もしてない。
素早く確実に出来るに越したことは無いよ。
出来れば良いんだよ。手段なんだから。
やらなくて良いことをやらないと決めるのもプロの仕事。
そう決めるにあたって、もちろん使ってみたり選定したりしてるけどね。
その選定や決断や調査にも工数かかるの。≒お金なの。
知らんで言ってるわけではない。
cloneするのは最初の一回、な。
常駐が入れ替わる度に数ギガのトラフィックか。
空論も良い所。
一回まともな体制のある程度の規模の開発に関わったらどう？ お、このスレでは日頃のストレスをぶつけ合えばいいのか？ >>509
悪く言うつもりはないよ
ただあまりに頼りすぎてるとそれがダメになった時に崩壊するってこと
原発然りデータ分散保存してなかった会社然り
コストカットをやり過ぎた結果が全電源喪失なったの忘れたの？
東日本大震災あってコストカットのために東京にしかデータ残してなくて全データ喪失しましたで顧客は納得するの？
二重に安全策を行っておくくらい基本じゃないか？
余談だが俺の会社に20年前のバージョン管理の履歴残ってるプロジェクトひとつもない なんかいきなり原発の話しだしてきワロタｗ
それとはぜんぜん違うだろう。 コストを削った代償の話で何も的を外してない
二重の安全策を怠った最も悲惨な事例だよ
高台に電源装置置いとけば事故は防げたんだから
過信といえばまだ二十年もたってないがアップルが経営危機に陥っていた時期に誰が10数年先にマイクロソフト抜いて世界一の企業になると予測できたか？
世の中本当に何が起こるかわからないよ 大きく的はずれだね。
必要ないと思っているものを削減するのと
必要あるものを削減するのとではぜんぜん違う。
また今度は関係ないアップルの話しだすし。
次はISISが戦争を始めるとかいいだしそうだ 原発おじさんはVCSの謎の突然死よりも
部下がこのスレに書き込んでいないかを心配した方が良いと思う 言いたいのは未来を予測できない以上二重以上の策を提供すべきということ
その必要かどうかはこの先ソースを保守する人間が判断するのであって今の人間が決めれることじゃない
20年前のプロジェクトの修正履歴見れるか試みたらすぐわかる話 サンプルでないコーディングで
foo だ bar だ hoge だのと >>512
うち、20年前のはコメントでの変更履歴がまだあるわww
未だ動いてるのが凄いんだけど。 >>519
うちもコメントやifdef等で残ってるのがある
修正入る部分にこれがあると何となく当時の背景が見えてくるから助かってる
バージョン管理は次々鞍替えして数年分しかない
どこが早く履歴の標準規格化してくれたらもっと分かりやすく差分や経緯を見れるんだけどな > 修正入る部分にこれがあると何となく当時の背景が見えてくるから助かってる
過去のバージョン見ればいいだけでは？
コミットログを見れば、何をしたのかもわかるし。 > どこが早く履歴の標準規格化してくれたらもっと分かりやすく差分や経緯を見れるんだけどな
差分の見方とコミットログの書き方を勉強しようよｗ
一体、何を標準化しろと言ってるのかわかんね。
お前なら、どういう規格を作るのか言ってみなさい。 >>521
もちろん過去のバージョンと台帳と突き合わせて見ればいいんだろうけど、
そこに変更が入っている事、がソース変更時に読めるのはわかりやすいよ。
今でもチケット番号だけ書いてる。
チケット番号書いとけば、コミット時に拾ってくれて、チケットに対象として載るしね。 > そこに変更が入っている事、がソース変更時に読めるのはわかりやすいよ。
ほぼすべての行に変更は入る。最初から何万行というコードが一気に出来上がるわけじゃない。
> 今でもチケット番号だけ書いてる。
ソースコードには、コードの意味ではなくてなぜそうしているか？を書く。
変更の理由という形ではなくて、なぜそうしたのか？を書かなければいけないほど
重要なことであれば、その理由を書いた上でチケット番号に関連付けるのは普通。
その場合は、コメント（チケット番号）は変更した理由という履歴ではく、
現在の姿として、なぜそうしているかという形で書けばいい。
変更したものを全部残すという考え方をしていると、現在のコードではなく
過去に存在し今は存在してないコードに対しての履歴まで残ってしまうだろ。
不要な履歴コメントは消すべきだ。 >>524
何が言いたいかわからん。
関数の頭のブロックにもチケット番号列挙してあるんだけど、
古すぎるコメントはチケット番号だけ残して消せば良いんだよ。
何故そうしているか、はコーダさん用のコメントだよね。
それらは本来、変更仕様書に書いてあるべき内容。
重要なことも何も、ソース改修はすべて重要な事だからチケット切って文書化すべき。
何故そうしているか、だけでは片手落ちも良い所。
○○年度○月○○法改正により計算方法が変更になり、下記の計算方法で計算する必要がある
以下計算式 資料 No.xxxxx Pp y-z及び…
なんて完璧にコメント書いてくのも、文書の方に書けと言いたくなる。
一切残さない、もありなくらい。 1998年度○月○○法改正により計算方法が変更になり、下記の計算方法で計算する必要がある
以下計算式 資料 No.xxxxx Pp y-z及び…
これは消していいだろう？ >>525
> 何が言いたいかわからん。
ソースコードに余計なコメントを書くな。
変更履歴も書くなって話だよ。
仕様は仕様書に書いてあるんだから、
documentディレクトリの○○テキスト参照って書けばいい。
仕様が新しくなったら、新しい仕様のファイル名に書き直すだけ。
修正のたびに行を増やす必要はなくなる。 >>526
1998年度以前のデータが二度と確実に入って来ないのであれば消しても良いと思うけど、基本は残すべきだと思う。もちろん文書に。
コメントとして処理内容を書くのであれば、これくらい書かないと片手落ち。
不足のあるコメントは余計なコメントに等しいよ。
>>527
だから、チケット番号で良いって言ってるんだけど。
文書載せられないようなトラッキングシステム使ってたらすまん。 >>523
ソースコードに書かれたチケット番号をBTSが拾ってくれるの？
というか拾って何になるのか判らないけど チケット＝作業、作業が終わるタイミング＝コミットなのだから、
チケット番号（≒Issue番号）はコミットログにつけるもんだと思うが？
特に重要な事に関しては、Issueに対してソースコードで注釈入れるけどな。
Issue駆動で開発すると
1. 新たなIssue（バグ報告や機能追加など）を作成する
2. それに対してのプルリクエストを作る
3. そのプルリクエストに1つまたは複数のコミットが含まれる。
4. そのプルリクエストをマージするとIssueが閉じられる。
という流れになる。
またプルリクエストっていうのは（Issueもだけど）、掲示板みたいなもので
それに関しての情報を時系列に会話するように記録できる。
最終的な修正内容をプルリクエスト（会話部分じゃなくて主文）に書いてそれをコミットすれば、
ソースコードのコミットログとして修正内容がバージョン管理される。
あとから修正を追いかけたいときはコミットログを見れば修正内容がわかる。
リンクも記録されてるから、コミットログからプルリクエストにもIssueにたどり着けるって寸法
これがgithubを使った主な開発のワークフローね。 >>530
拾ってくれるよ。コミット時に。
ソース管理もバグトラックも出てくる帳票も全部連携してる。
コミット時にも書けるけどね。
どの関数に手を入れたかわざわざ手で書かなくても良くなってるのと、
ソースとリリースノートだけ読んでもある程度わかるように。
あと、逆にリリース用チェックアウトした時にリビジョン等のスタンプも押される。 手動でソースコードに変更履歴書いて
古いコードを残す文化とまるで違うｗ >>532
チケット番号←→コミットログ←→変更ファイルで芋づる式に取り出せる情報なのに
人間が変更ファイルをマーキングして周ってるのか
本人が言ってるならそうなんだろうけど随分変なやり方してるね >>534
正確には変更ファイルにマーキングしてる訳じゃないよ。
変更箇所にマーキング入れてるだけ。
いつでもdiff取れるわけではないからね。 > いつでもdiff取れるわけではないからね。
いつでもdiff取れるようにしなさいよｗ
あほだなぁ。 >>535
納得した
そういうやり方ならありかもね
つってもソースコードから参照されてるチケットが陳腐化してないか
一々管理しなきゃならない不毛さを思うと
その時間でコメントを真面目に書けよって思うけどねｗ >>521
その時コミットログ見れればそれでベストだが環境移行等で見れなくなった時の話
>>522
差分やコミットログをどんな環境でも見れるためのファイルフォーマットだよ
ファイル仕様が決まれば別のバージョン管理ソフトも必ず対応するからOS変わろうがツール変わろうが将来見ることができるだろう
コードが理解不能になって作り直しってのはよくあるからな > その時コミットログ見れればそれでベストだが環境移行等で見れなくなった時の話
見れなくならないように、ちゃんと環境移行すればいいだけ
> 差分やコミットログをどんな環境でも見れるためのファイルフォーマットだよ
差分はgit diffでテキスト形式に変換される。
gitじゃなくてもすべてテキスト形式に変換できる。
テキスト形式が見れない環境など無い。 >>539
同じところにも存在してればなんとかなるかもしれんが配置変わったり消したりするのは普通に発生する
その時見れないのでは話にならない
古いプロジェクトやったことある人間ならわかると思うが修正履歴が完全に残ってすぐ見れるなんて夢物語
ドキュメントなんてないしあっても嘘八百
ソース=仕様ってのしかお目にかかったことないわ
10年くらい放置されてて突然手を加えるとなったときには開発環境が動かせないとかなw >>536
そりゃまあ、もちろんそうだけどね。それが実現するなら構わんけど。
地震が起きて、停電は起きるわ、窓ガラスは割れるわ、
支社とネットワークが上がらないわ、端末の何割かが壊れるわ、
なんやかんやで大変な事になっても
「今差分取れないし履歴も読めないのでわかりません、復旧まで待ってね」って投げちゃえるなら全部電子媒体で持ってて、必要な時に必要な分を随時取り出してもいいだろうね。 >>541
火事になって会社焼けたら困るなら、
別の所にあるHDDとコンピュータを使えばいいのでは？ 紙媒体だと、燃えたら全損だからな。
バックアップも取れないだろうし。 >>540
だから、デジタルで記録された、現在動いている
ソースコード以外役に立たないんだよｗ．
いくら紙の資料があっても、それが最新とは限らないからね。 >>540
> 古いプロジェクトやったことある人間ならわかると思うが修正履歴が完全に残ってすぐ見れるなんて夢物語
古いプロジェクトからずっとバージョン管理してるわｗ
修正履歴が残ってないのは、バージョン管理していない頃と、
紙媒体で履歴を保存していたものだけ。 地震でてんやわんやですが、
「差分取れるし、履歴も読めます。ただ、沢山の紙の資料の中から
探すのに時間がかかるのでちょっと待ってください。
パソコンを直すよりも時間がかかりますがねｗｗｗ」 俺なら、地震で仕事にならないなら、
別の場所に支社があるんだろう？
そこに仕事まわすだろうな。
デジタルデータなら共有も簡単なので、そっちで差分見ればいい。
紙に保存した資料に頼ってるから、余計大変なことになってるわけで。
命の危険もある中で、地震で散らかっている倉庫を探しまわって
仕事をする必要はない。優先順位を考えれば当然そうなる。 >>545
紙で履歴保存してた頃にソース記述しとけば今でも見れたわけよ
俺は履歴は現行ソースと同等レベルで重要と思ってる
履歴がなくてコメントもろくにない中データ保存に分割してよくわからん計算してる理由わかるやつなんかそうそういないわ
わかった時には脱帽したよフロッピー先輩w
履歴あればすぐにわかったんだろうがな
今の時代にデータ保存にそんなことしない無理すぎた >>542
火事になっても大丈夫なように複写は他の所にも保管はしてあるよ。
>>543
お前コピー機も知らないの？
>>544
それは管理の仕方次第
>>546
探さなくても台帳、リリースノート、変更仕様書、等々キングファイルに綴じてあるからすぐ見つかるよ。
>>547
サブシステム毎に担当わかれてるからね。
こっちの命の危険なんか関係ないよ。
客先にはどんどん怪我人搬送されてたり、自家発電切れそうで縮退運転始まったり、
それこそこっちが一人二人死んだ位どうという事は無いよ。ただの労災。
命を預かる物作ってるのに、その責任に自分の命を代えられないほど情けない人間でもない。 支社があるような会社の運用ではないように見えるのだが >>551
平時とは違うよ。
それこそ電子化されたもの見りゃいいからね。
電話が復帰したら関西に投げたし。
当日翌日があんな状態になってもちゃんと回っただけいい方だと思うけど。
>>552
古い物を知らん奴が、解決策も無く古い物は良くないと言ってもなんの説得力も無い。
中学生の政治への憤りみたいに見える。 資産を異なるメディアでバックアップする事と
ソースコードからドキュメントを自動生成する事は完全に別問題なんだけどね
今後者のアプローチとして突っ込みが入ってるのに
なんで災害を強調するの？ 災害だと体験した人が少ない。
それは「俺にはわかるがお前らにはわからんだろ」
という上から目線をいうことができるということを意味する。
わからんと思うことなら説明するのが筋なんだが、
説明ができないので、別の方法で代用する。
それが「お前らにはわからんだろ」という言葉で
圧力をかけること。そのために災害を強調している。 何の根拠もなしに、古いものを知らないと断定出来る才能自体が老害だとは思う。 >>555はこういう喩え話でも説明できる。
あるとき若者が戦争についてあれこれ議論しているとする。
戦争について興味が無い人が多い世の中で素晴らしいことだが
そこで老人が現れて一言言う。
「戦争を実体験していないお前らに何がわかる？」
これでもう議論は止まってしまう。わからないのは事実だし
それはどうしようもないこと。その老人に勝つことは出来ない。
これは老人が正しいことを意味するわけじゃない。
例え老人の言うことが100%間違っていたとしても、
「お前らに何がわかる？」と言われれば反論できない。
議論の内容ではなく、その外側から圧力をかけて
黙らせているだけにすぎない。実に便利で姑息な手段だよ。 何で、発作のようにはねっかえって来てるのかわからん。
システムも、アナログな管理でも、管理さえ出来てれば良いよね、ただの運用のための道具、手段だから。
ってだけの話でしょ。
よほどなんか負い目あるの？ ほんとね、理由言わずに無駄っていうやつ、何なんだろうねｗ
水掛け論始めたいのかってな。 >>561
> システムも、アナログな管理でも、管理さえ出来てれば良いよね、
管理できるのは最低限で、効率的に管理して
コスト削減するのが、システム化の目的の全てでは？
当たり前すぎて、これだけで論破（笑）出来てしまう気がするが。 >>566
その、最低限が業種によって違うよね。
って話してるのに、何言ってるの？
コスト削減、無駄の排除とそれは相反しないよ。
たとえれば、命綱はかける手間が無駄だから省略、作業場所に敷くマットは高いので敷かない、すべてロボットで窓ガラス拭きます！なんて話だよ。
その上で窓ガラス拭くならロボットで良いし、拭けないなら拭けるまで待っても死人が出ないからそれでいいね、って話だし、
災害時用の電波塔なら、拭けないなら拭けるまで待つなんて出来ないんだからいざという時は人が作業できるように体制は保持しようね、って話なんじゃん。
全然ソースコード関係ないけど。 >>567
じゃあ文句言う対象は俺じゃねーだろ。
「無駄」と言った奴に対して、
最低限は業種によって違う。
無駄じゃないかもしれないだろって
説教たれろよ。
一般論でしか無いし全く無意味な説教だがな。 管理さえできていればいいよね・・・そこで思考停止
管理できるのは当たり前で、効率的に管理するのが重要・・・思考停止していない。 >>568
何をそんなにいきり立ってるの？
明後日のカイゼンかなんかを提案して怒られて拗らせてるの？
>>569
管理さえ出来ていれば良いとしか言いようがないでしょ。
もしアホ揃いで紙運用回す能力もないなら、それは「紙では運用管理出来ない」んだから、管理出来ていない≒何らかのソフトで運用しなければならない、だよね。
まんま同じで、システムだけでは回らないのであれば、それは「システムでは運用管理出来ない」なんだから、紙モノも残さんといかんな、って話じゃん。
何も否定してないのに、アホなの？
全部手段で道具で、目的は「満足に管理して業務を回すこと」だよね。
思考停止でも何でもないよ。 >>570
> 何をそんなにいきり立ってるの？
俺に言うべきじゃないことを俺に言うからじゃん。
> 明後日のカイゼンかなんかを提案して怒られて拗らせてるの？
お前の思い込みって、ほんと面白いよなｗ そんなの実経験から思いつくの？ｗ >>570
だから管理できるのは最低限だって。
ここから更に効率が良くてコストも低い方法に変えていくの。 >>571
俺に言うべきこととかどうでもいいよ。
よっぽど自己評価高いのな。
実体験から思いつくよ。よくこの類のダメ出しはするから。
>>572
何言われてるか理解できなければいいよ。
結果論として無駄に効率が悪くて無駄にコストがかかる運用なんて、その最低限を満たして無いよね、って話。 VCS標準化おじさんに原発おじさんに
面白い人がよく集まるスレですね 導入コストっつーか慣熟期間に一時的に落ちる効率が
導入後に取り返せる見込みがない場合ってあるよな。
太陽光発電システムを数年スパンで丸ごと入れ替える
みたいな、全然元が取れてないパターン。 俺が正しい
俺だけが理解している
俺の意見が理解できないやつはクソ
という論調の書き込みは読むに値しない
例え正しいことが書いてあったとしてもな >>577
正しくないぜ
当然じゃないかハハハ( ´∀`) hoge[1] = 89123;
hoge[2] = 123;
hoge[3] = 1234;
hoge[4] = 14323;
hoge[5] = 1123;
hoge[6] = 15623;
hoge[7] = 3123;
hoge[8] = 1323;
hoge[9] = 1223;
hoge[10] = 1234; hoge[1] = 89123;
hoge[2] = 123;
hoge[3] = 1234;
hoge[4] = 14323;
hoge[5] = 1123;
hoge[6] = 15623;
hoge[7] = 3123;
hoge[8] = 1323;
hoge[9] = 1223;
hoge[10] = 1234; あー、これ系のソース書いたことあるわ。
バイナリファイル中のファイル位置、サイズだったか、
固定長電文のフィールド位置だったか。 データセットを DataGridView に表示するのに、バインドせずにループで回して代入。 >>582-583
バインドなしループなしを見たことがある >>584
> データバインドとかここ10年くらいのものだろ
いつが最初かしらないけど、Visual Basic 4.0の時代にはあったよ。
1995年発売だから20年前だね。
http://windowsitpro.com/windows/visual-basic-40
http://windowsitpro.com/site-files/windowsitpro.com/files/archive/windowsitpro.com/content/content/2494/screen_01.gif
古くてちゃんとした情報は見つけづらいけど、MSRDC、RDO、DAO、DBGridあたりの
キーワードで調べれば断片的に見つかるはず。
ウェブのGUI技術なんて20年前の歴史を辿ってるだけだからさ。 0=Off, 1=On を表すパラメータと、0=On, 1=Off なパラメータが混在していて
どっちがどっちかは列挙型の名前で区別するようになっているのだが
その名前付けが間違っている
enum FLAG_0_IS_OFF { OFF = 0, ON = 1 };
enum FLAG_1_IS_ON { ON = 0, OFF = 1 }; ■ このスレッドは過去ログ倉庫に格納されています
