アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
で、 (スコア:1, すばらしい洞察)
Re:で、 (スコア:2, 参考になる)
GPL [gnu.org]の条文で言うところの3-bの採択をしようとしていると思われるのですが、これで十分なのかどうかは判りません。該当製品全てに対して今から文書を送りつけろと言うのはさすがに難しい話だとは思いますが。
KyaTanaka
Re:で、 (スコア:1, 興味深い)
学生の頃のバイトですが、元々プログラム書いていた人が雇用主と喧嘩別れする事になってそれの後を引き継いだんです。で、ソースみてみたらただのDisA
Re:で、 (スコア:1)
ランダム文字列置換とコメント削除ってのは目的が判らない。
なんで?
Re:で、 (スコア:1)
余談ですが、某顧客が、ソース中の関数名を通し番号にすることを要求してきたんで、
ランダムでこそないけど人間可読性は最悪なソース、を
納入した(せざるを得なかった)ことなら有ります。
ちなみに、書
Re:で、 (スコア:2, 興味深い)
私も以前、某大手企業でJavaの仕事をしたときに、ファイル名と関数名を品質管理番号に変更して欲しいと言われて、目が点になったことがあります。
「そんなことしたら、メンテナンスが大変じゃないんですか?」と尋ねた
Re:で、 (スコア:1, 参考になる)
ローカルな変数名はさすがにBUHIN-BANGOとかの可読なものになっていました(しかしSIZAI-CODEはいいとしてもSIRIARU-NANBAAとかはやめて欲しかった)。
運用担当者は
Re:で、 (スコア:1)
1:
モダンな言語では、言語の構成がだいぶ変わったんで、
COBOLとか(でしょうか?)と比べると、「ローカル」なものが増えたのでしょうね。
というか、ローカルだなんだという区分のパターン自体もだいぶ変わりましたよね。メンバ変数とかさ。
2:
可読な文字列を扱うための技術…一番すぐ思いつくのは「検索」…が、飛躍的に向上した、のでしょうか。
大昔の環境のことは俺は全然知らないんですが、
やっぱり、計算機に「検索」させるのは、
Re:で、 (スコア:0)
> モダンな言語では、言語の構成がだいぶ変わったんで、
これもあるとは思いますが、そもそもシステム構成やら、
その上で動く処理の構成からして「モダン」ではないってのもあります。
あと、ミドルウェアの絡みもありますし。
だから、個々の言語の問題だけとは言い切れません。
>2:
>可読な文字列を扱うための技術…一番すぐ思いつくのは「検索」…が、飛躍的に向上した、のでしょうか。
検索もすると思いますよ。今なら普通。
ただ、それ以前の問題として、「言葉」やら「紙」で情報が伝達される
環境もあったりします。
非効率だと思うかもしれませんが、セキュリティ上処理されるレベルが違うと、
ネットワークが繋がってない環境とかもあったりします。
それに「言葉」とか「紙」の情報から検索する場合、
規則性がある単純で短い方が楽だったりします。
単語の聞き間違いとか、打ち込みミスもしにくいですし。
そんなの逆だろと思うかもしれませんが、規則決めるときに、
よっぽど紛らわしいつけ方しなければ案外そんなもんです。
人間が理解できる名前の方が勘違いしやすかったりします。
もちろん、オープンな開発で、仕様書とかか、
運用時の状況がはっきりしてないとかの場合は、
こんなローカルな規則性では、一々覚えるところから始めるのは、
馬鹿らしいでしょうが、ローカルな運用環境だと、
短い一見意味不明の単語でも、多くの情報が読み取れます。
この辺って、運用をしたことがないとわかりにくいかも知れません。
たとえば先の例を引用して、A320とA321と言うJOBがあったとして、
実はコードはまったく同じだったとします。
開発側から見たらだったら同じ名前で良いだろうと思うでしょうが、
運用レベルだと、まったく違うもので、A320とA321を間違えたために、
大損害になる・・・と言うこともありうるわけです。
で、A320とA321の違いってのは、短い分すぐわかると。
開発側からしたら中身を名前で表したいと思いますが、
運用としては、違いと種類を分けて考えたいと思います。
この場合、Aが中身を、320等が種類です。
まぁ、運用といっても規模やら環境にもよるでしょう。
1:であげられてるようなコボルな環境だからかも知れませんが。
ちなみに開発畑出身ですが、コボルな開発はしたことありません。
が、ソース見てるとスクリプトみたいで単純な気が(とか言うと笑われるかも)
Re:で、 (スコア:1)
なるほど。味噌はここなのでしょうね。
>馬鹿らしいでしょうが、ローカルな運用環境だと、
>短い一見意味不明の単語でも、多くの情報が読み取れます。
>この辺って、運用をしたことがないとわかりにくいかも知れません。
いや、こっちも無いわけじゃないです。運用も開発も。
…ただ、肝心のコード体系の管理が甘甘だったので、
いつも仕様が混乱しバグが取れないでいましたが。
意味ないじゃん。
#部署ごとに更にローカルなルールが有ったりなんて…つきあってられませんって。
#せめて、それらの情報をまとめてから、話を持ってきてくれないとなあ。
>が、ソース見てるとスクリプトみたいで単純な気が(とか言うと笑われるかも)
単純ならばScript言語になれますが、
単純なだけでは、「モダンな」Script言語にはなれません(^^;
Re:で、 (スコア:0)
> いや、こっちも無いわけじゃないです。運用も開発も
その通りですね。
開発だって、短い名前でも規則性があって、
ちゃんと仕様が決まってれば、問題ないわけで。
> #部署ごとに更にローカルなルールが有ったりなんて…つきあってられませんって。
> #せめて、それらの情報をまとめてから、話を持ってきてくれないとなあ。
これも確かに、その通りでしょうね。
結局はどこまでちゃんと仕様(って言うか要件定義も)を煮詰めてるか、ですね。
開発側も運用側も含めての。
> 単純ならばScript言