アカウント名:
パスワード:
ポータルなどは本当にたくさんのサービスがあるので、サービスごとに違うアーキテクチャを採用しようと思えば出来る。しかしそれをやってしまうと「統一してよ」と運用部門(Operation)が怒るのは目に見えている。 また、サーバーを買うからには同じアーキテクチャでそろえた方が、余分な作業なしに使いまわしが出来たりして、足りない部分に簡単に振り分けられるので資源の有効活用が出来る。エキサイトのようにハードウェア投資にシビアな会社は、こっちはPHPで書いたので別のサーバーを買うなんてことはしない。 出来るだけ同じアーキテクチャで統一し、どのプログラムがどのサーバーでも動くようにしておいた方が、冗長性があるというものだ。これはハードウェア購入だけでなく、ラックスペースに払う金額もセーブできる。
この提案の最も非現実的な点は, 何十年に渡ってメンテナンス出来る人材を確保・維持することが事実上不可能なことを無視していることです.
仕様書があるがことごとくそのとおりにできていない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
思いっきり素人がなんですが… (スコア:3, すばらしい洞察)
しっかりとした分業体制や継続開発・後々のメンテが出来る体制さえ出来ているならば、使う言語は使い慣れたもので良いやとか、いざとなったら別の言語に乗り換えてしまえとか、そんな感じなのではないですかね?
もちろん、そんな体制が簡単に築けるなら苦労はせん、というのが実情なのだろうというのは、分かりますが…
#ホントに素人考えなんです。
#業務でデスマーチなコトになっている皆さん、気に障ったらごめんなさい。
-+- 想像力を超え「創造力」をも凌駕する、それが『妄想力』!! -+-
Re:思いっきり素人がなんですが… (スコア:2, 興味深い)
野良猫コーダーなので大規模とかチームとか縁遠い言葉なのですが、人や開発体制ってそんなに安定しているとは思えず、崩れた時に言語や環境、フレームワークといったセーフティーがあるなら十分にポイントになると思います。
そういう部分は Perl/PHP にアビリティが無いとは思わないのですが、国内では未成熟な部分だと思っとります。
> 使う言語は使い慣れたもので良いやとか、いざとなったら別の言語に乗り換えてしまえとか、そんな感じなのではないですかね?
については元記事のエッセンシャルサーチエンジンで
とカウンターになる理由が語られています。
エグゼクティブの視点だと思って読むと説得力は高いです。
Re:思いっきり素人がなんですが… (スコア:1)
>サーバーでも動くようにしておいた方が、冗長性があるというも
>のだ。これはハードウェア購入だけでなく、ラックスペースに払
>う金額もセーブできる。
これはよくわからんなー。
Javaしか動かないハードウェアとか、PHPしか動かないハードウェアっていうのが
あるわけじゃないよね。JavaでもPHPでも、たいがいのマシンで動くし。
なんで使用言語を統一することがハードウェア購入金額の節約に結び付くの?
ほんとうにわからないので教えてください。
#運用コストが下がるのはよくわかるんだけど。
Re:思いっきり素人がなんですが… (スコア:1)
プラットフォーム依存になっているものがけっこうあります。そういう場合は,作ったものは他に持っていけなくなります
ね。DB周りなどはそういう話がすぐ出てきます。JavaのServletだとwarを持っていけばOK(というのは言い過ぎですが)
なので,やっぱりラクです。
Re:思いっきり素人がなんですが… (スコア:1)
>フレームワークといったセーフティーがあるなら十分にポイントになると思います。
個人的には、プロジェクトの安泰(^^;にとっては、
安定性よりも「ヤバいと思ったとき、如何に素早くヤバくない状況に変化できるか」のほうが
重要なんじゃないか?という予感がしています。
そういう意味では、言語や、特にフレームワークは、
元々「1つのやりかたを押し付ける」ものなので、
むしろ変化に対する足枷になるという節を感じています。
旨くはまればそれでOKなのですが、一旦どこかにズレが生じると、途端に脆いんですよね。
なので、フレームワークはセーフティじゃなくむしろ急所だという気がしています。
一方、Lispのような(実際にLispがそうであるかどうかは知ったこっちゃないですが(笑)、
Lisp勢が主張する言葉を信じるならば、という意味です)今時の計算機にやれることが
ひととおりなんでも柔軟にやれる奴ってのは、有利なのかも知れません。
もっとも自由度が高いぶんだけ人員の力量を要求しますが。
蛇足ですが、フレームワークというものの進化の最終形態として、「言語」が挙げられるそうですね。
そのフレームワークらしさを出す「或る面」についてはプログラマを縛り続けるけど、
それ以外の面については極力高い(カスタマイズの)自由度を提供しようとすると、
それは「言語」になっちゃうものらしい。
#まあ言われてみれば、ガベコレもXXXX指向も「フレームワーク」だよなあ…
----
ところで、体制と安定についてですが、
神ならぬ人間の集団(しかも現場の限られた人員だから、能力の期待値は更に低い)
であるプロジェクトってものは、「悪い方向に安定」してしまうことが有るようです(^^;
どーしてこいつらこんなにDQNな選択ばかりするかな?みたいなことが、
コーディングにせよマネージメントにせよ、頻繁に見受けられます。
しかも、プロジェクトが1つの閉じた世界として「外界からの(良い)影響を拒絶」することすら有る。
ああ、危ない危ない…
Re:思いっきり素人がなんですが… (スコア:1)
> なるような気がします。
私もここがポイントなんだと思います。で一つ問題提起させていただきたい。
大きな企業の場合は大抵信用を重んじるので、既に実績のあるもの、90年代に実績がある Perl, PHP を選択すると思います。そして猛烈な資金を投じて(リファクタリングもさせない、堅いプロセスで)使い捨てプログラムを書かせます。数ヶ月で状況変わるからそ、のたびにプログラムも一から書き直させればよいということなのでしょう。
しかし「メンテナンス費用はかかる。寿命は数ヶ月。そんなものに投資していていいのか」と問いたい。大企業ならともかく、中小は100%ムリ。
だから、中小にははシステムの資産と負債の違いを知って、資産にだけ投資していただきたい。で、その観点から技術基盤の選択をすると、PHP や Perl では綺麗なコードは書きづらいので(負債をせっせと作ってしまう)、永続的なメンテナンスがしやすい Python か Ruby を選択してほしい。そして、何十年にわたって使える資産、リファクタリングされたメンテナンスしやすいコードを書くのがよいでしょう。
Re:思いっきり素人がなんですが… (スコア:2, 参考になる)
Perlはたしかにいろんな書き方ができるし省略記法が多すぎるので
綺麗なコードにはなりにくいですが、PHPはそんなことないのでは?
どちらかというと、PHPの問題は(ほかのコメントにもありますが)
HTMLとロジックとをごちゃごちゃにしてしまいがちという点でしょう。
でもまあ、いちばん綺麗なコードが書けるのはRubyでしょうね。
Javaも綺麗なコードが書けるし汚いコードになりにくいですが、
RubyはJavaに負けず汚いコードになりにくいし、Javaよりはるかに
簡潔に書けるのがうれしい。実行速度に言及されると弱いが。
#Pythonはよくしらんのでパス。
Re:思いっきり素人がなんですが… (スコア:1)
この提案の最も非現実的な点は, 何十年に渡ってメンテナンス出来る人材を確保・維持することが事実上不可能なことを無視していることです.
Re:思いっきり素人がなんですが… (スコア:0)
それが下っ端コーダ君なら派遣でも雇って補充すれば良いのだけど、
リーダークラスの人間が辞めた時のダメージは計り知れない物がありますね。
たとえしっかりとしたドキュメントを残していったとしても、そ
Re:思いっきり素人がなんですが… (スコア:1)
>90年代に実績がある Perl, PHP を選択すると思います。そして猛烈な資金を投じて
>(リファクタリングもさせない、堅いプロセスで)使い捨てプログラムを書かせます。
「かたい(「堅い」というほど肯定的な意味を持たせるのは不適切だと思えるので
「硬い」「固い」のほうがいいと思います。「難い」でもいいかも(藁))プロセス」
は、
「大企業(に限るまいが)が必要とするような信用」に耐えるプロセスではない、と
最近痛感しています。
むしろ逆に、パワーのある企業で、コードを幾らでも使い捨てに出来るというならば
(そんな組織が存在するとは俺には信じ難いですが、それはともかく)、
選択すべきはむしろ「使い捨てにしやすい言語」つまりそれだけ「高速に書ける言語」
じゃないかと思います。
そういう意味ではRubyとかのほうがイケてると思います。Java(や無論C++)より。
ん?ああ。
要するに、大企業も中小企業もどちらもRubyとかのほうがいいじゃん、という話です(笑)
#言語の硬さよりも、柔らか言語+自動テストばりばり、のほうが余程安心できると思うのでG7
#言語の硬さなんて所詮、型とかの「本質とはちょっとずれた」部分しか保証できないんだからさ。
なお、「信用」が「納品物の品質」ではなく(笑)「言語の選択」を指す言葉だと(その大企業が)思っているのだとするなら、
俺に言える一言は「それ、幻想ですよ。」だけです。
「実績ある言語」なんて概念は、あんまり意味がないです。
なんせ言語(メジャーどころ)は「改良」され続けてるんですから。
もし不幸にして改良されてない言語が存在したとしても、そんなもんは最初から選択肢に入れなきゃいいだけなので無視。
----
余談:
字数が嵩む言語も、コピペを多用すれば確かに「書く」時間はそんなに食わないんですが、
コピペすると今度は「読む」のに時間がかかるんですよね。
コピペらしき個所が、以前出た個所と「同じ」ことが書いてるのか「少し違う(バリエーション)」ことが書いてあるのかを
いちいち確認しないとならなくなりますから。
これがLightWeight言語だと、もともと何も書いてない場所にはバリエーションのつけようが有りません(笑)から、
さくさく読める。#WhiteSpace言語じゃないことをお祈りしますが。
RubyとJavaの比較で言えば、まず感じるのは内部イテレータの有無ですね。
Javaには無いので、ループとかを書くときに必ず「余計な」字数を要する。
おまけに余計な変数(イテレータやループカウンタ)まで要する。
そういや、デザインパターンをパターンとしてしか記述できない言語は辛いよね、という話が
Ruby方面で有りましたっけ。
もしパターン(レシピ)じゃなくライブラリ(完成品)として用意できるなら、そのほうが便利に決まってる。
Re:思いっきり素人がなんですが… (スコア:0)
>が余程安心できると思うのでG7
>#言語の硬さなんて所詮、型とかの「本質とはちょっとずれた」
>部分しか保証できないんだからさ。
この比較は、ちょっと不当なんじゃないかという気がしますが。
まさか、硬い言語だからといって、テストし
Re:思いっきり素人がなんですが… (スコア:1)
このへんを勘違いしてるアホどもの実在 (
実際、「そこはテストするまでもないでしょ」と(勝手に)決め付ける奴、居ます。
その見切りを人間じゃ完璧に出来る保証がないからこその、テストだろうに…
ええ。品質は、そりゃもう…(T_T)
) は、さておくとして、
>それとも、硬い言語では、自動テストばりばりは
>難しいということなのでしょうか。
まあそういう言語も(そうでない言語も)ありますが、それもさておき、
問題は、「型(硬さ)」と「テスト」の有効度の違いでしょうね。
「テスト」のほうが結局遥かに役立つ。
それに比べたら「硬さ」の価値なんて霞んでしまう。
霞んでしまうなら、手数が増えるだけの硬さなんて、邪魔。
Re:思いっきり素人がなんですが… (スコア:0)
>問題は、「型(硬さ)」と「テスト」の有効度の違いでしょうね。
>「テスト」のほうが結局遥かに役立つ。
>それに比べたら「硬さ」の価値なんて霞んでしまう。
>霞んでしまうなら、手数が増えるだけの硬さなんて、邪魔。
柔らかい(動的型?)言語では、硬い言語ではコンパイラが行って
くれていたチェックを、テストで行わなければならないと思うん
ですが、それを網羅的にきちんと行うコストって、それほどまで
に小さいものなのでしょうか?例えば、全てのクラスについて、
型エラーを検出するテストコードを入れるとすると、その手間
は小さい
Re:思いっきり素人がなんですが… (スコア:0)
Javaはメンテナンスのためのツールは豊富な気がするのですが…。
# EclipseからVC++.netに戻りたくない症候群
Re:思いっきり素人がなんですが… (スコア:1)
ここでいう大規模っていうのは、大きな資本があって、多くの人にサービスを提供していて、信頼性が一番重要な価値を持つってことですよね。複雑なものなので大規模になるっていうわけじゃない。
Re:思いっきり素人がなんですが… (スコア:0)
まともな開発体制のWeb屋ってめったに無いですよねぇ(笑)
「今動いているものが仕様」っていうだけの引継ぎで、途方にくれることがしょっちゅう。
Re:思いっきり素人がなんですが… (スコア:1, おもしろおかしい)
これならまだマシです。
一番ひどいのは、 だと思われ。
Re:思いっきり素人がなんですが… (スコア:0)
同じ事柄に対して複数の仕様書が存在し(それも膨大に)
それぞれが矛盾していてどれひとつ確実に正しいとは言えない
....当然動いているものは仕様書とかけ離れてしまうわけで....
つーかメンテできないなら仕様書書くなと
Re:思いっきり素人がなんですが… (スコア:1)
お客にドキュメントを納品する、という意味でのドキュメントなら、
まあ勝手になんぼでも書けばいい(ただし開発者に負担をかけないならば(笑))んですが、
問題は、ドキュメントの本来(!!!)の価値であるはずの「後で役立つ」という点が
ないがしろになることがしばしば有る、という点でしょうね。
後から読んでも意味不明とかの無価値なドキュメントは、
無駄になるのが判りきってるし、
そもそも後から読んで判らないものは大抵、今読んでも判らないわけで(笑)、
つまりそのドキュメント自体に存在価値が無い。
存在価値が無いものを、単に契約とかを満たすためだけに書く、ってのはアホみたいです。
そんな契約をするよりも、「役に立つドキュメントを書け」という契約をするほうが
(どちらにとっても)遥かに良いことであろうに。
#全面的OOPなシステムのくせに「クラスの」仕様書が不在で、お手上げなG7
Re:思いっきり素人がなんですが… (スコア:1, 興味深い)
ああするだけで開発に入る事も多い今日この頃。
以下周りで良くある話
-----------------
A:仕様書?。仕様書を作るのに1人月くれるの?
B:でも仕様書が無いと客に納品できないんですよ。
A:でも予算でないんでしょ。
B:そうなんですけど・・今後の保守の為に・・
A:あんた・・保守て・・ここ何回も別のプロジェクトで
XXなんですけど・・XXになるのでしょうか?とか
聞いてくるけど、その度に、「仕様書」に記載してある
と言っているのに、全然見てないじゃんあんた・・。
B:申し訳ない・・。
Re:思いっきり素人がなんですが… (スコア:0)
って何?7年間で一度も・・
Re:思いっきり素人がなんですが… (スコア:0)
長い人生において何度も出会えるものではありません。
それをたった七年で出会えないからと言って、何かと聞いてくるのは
いかがなものでしょうか?(笑)
Re:思いっきり素人がなんですが… (スコア:0)
あたしゃ「まともでない」ほうが少ないな。
むろん皆無ではないけれどさ。