生産性、効率性を重視した開発環境
■ このスレッドは過去ログ倉庫に格納されています
生産性、効率性を重視した開発環境とは、
・使っていて楽しい。苦痛でない。
・トラブルが少ない。安定している。
・データベースとの接続性が簡単。SQLを書かなくても良い。
が、SQLを直接渡す手段も一応用意されている。
・コーディングの量が少ない。人海戦術に頼らず、少人数で多くの機能を短期間で実現できる。
・Web鯖、AP鯖、DB鯖との連携が透過的でわかりやすい。
・分散開発環境に対応している。
・できれば、HTMLとビジネスロジック部分を完全に切り離して開発ができる。
・安い。
・アプリケーションのパフォーマンスが軽い
・メンテナンス性、拡張性がズバ抜けて良い。ちょっとの変更の
ために最初からソースを追いかけるような手間がいらない。
上記の条件を全てとはいわなくても、クリアしている開発環境はないだろうか。
perl、Servlet＆EJB&JSP、PHP、WebSphereときているが、
特に生産性という面では、優れた技術・開発生産性を
誇るツール群をみたことがない。イロイロと試したいが時間がない。
何かオススメはないだろうか。 なんでこういうスレを立てたかたというと、知り合いの会社が
perlで書いたシステムをどっかの会社に納めているのだが、
とにかく仕様変更と名の付く修正が入ると、毎日、社員総出で
時には外部に頼んで、それこそ人海戦術で闘って(?)いる姿を
何度も観ている。ワタシも手伝ったことが数知れず。
ここに来て、他のSIが入ってきて、どこぞのツールを
駆使しているかは判らないが、エンジニアの人数もperlで
書いてる連中よりも半分以下、工数も今より少なくて
値段もそれなりに安いということで、今後の展開がヤバそうという
話を聞かされた。
対岸の火事ではなく、自分も同じ境遇にあり、色々とツールを
あたっているのだが、決定打となるべきものが見あたらない。
どれもこれも、コーディングの量はハンパではなく、
複雑になってしまうのだ。
それに対し、Webアプリだから納期も今までより短く安くできると
トンデモナイ勘違いをするクライアント。
だからといって、こちらの苦労なんで相手には判らない。
と、いうわけで、少しでも（できれば大幅に）労力の少なく、
できればビジネスロジックに集中できるような開発ツールを追い求めています。
経験豊富な２ちゃんねらの皆様の経験を求む。 長々とｽﾏｿ.
WebLogic、WebSphere、OracleApplicationServerといろいろな開発
環境をデモ版でテストしたりしたのは良いのだが、コーディング量
というよりは、J2EE関連は結構複雑で、perlしかやったことのない
連中には非常に敷居が高く感じる。DQNと言われればそれまでだが、
JE22を取り巻く技術を習得している時間や労力、コーディングの量など
を考えると、ある程度AP鯖側でたとえばHTML展開の為のコンポーネントが
用意されていて、それを使うだけで良く、カスタマイズも簡単に。
というのはないだろうか。
あるといえばあるのだろうけど、問題はコスト。開発環境は
それなりに安くても、運用の為のソフトウェアがバカにならない。
ヘタをすれば数千万になるケースもある。クライアントが
買えば良いのだが、おいそれと提案できない状況下にあるのは
ワタシの会社だけじゃないはず。
だからといってフリーの環境になると、先に書いた途方もない
労力、人海戦術が待ち受けている………ｳﾄｩｰ... >>4
さっそくのレスに感謝！
WebObjectというのは初めてききます。
アップルの製品ですか。ワタシはマックについては全く判らないのですが、
コンシューマ向けのハードウェア製品を出しているメーカが
アプリケーションサーバー向けの開発環境を提供しているとは、
意外ですね。。。 >>1
漏れも興味あるんで、がんばって良すれにしてくださいage >>4
ざーーーーっと、そのスレと、アップルのホームページを
みましたけど、なんか、眉唾といっては、アップル信者に
怒られるかもしれませんが（笑）、
大丈夫なの？ってカンジもします。。。
（でも、ＣＳＫが採用しているくらいですから、ちゃんとしたツールなのでしょかね？） >>6
ありがとうございます。がんばります。
本当に、今のWebアプリを開発する環境というのは
生産性や効率の面でみれば、ぶっちゃけた話、VBやDelphi以下だと
感じています。とにかく、一度作って修正が入ると、その労力は
若い人でも長丁場になれば精神的にも苦痛でしょうし、
何より最初からソースを見直したり動作テストをしたり、HTML展開の為に
調整をとったり、SQLをゴリゴリと書いたりと、
経営的な立場から言わせていただければ、はっきり言って効率悪すぎです。
そういうことを繰り返しているので、思わぬバグが思わぬところから
出てきて担当エンジニアがテンテコマイになってしまい、
結果的にクライアントに迷惑がかかるなど、良いことが一つもありません。。。
単に我々の技術が低いだけかもしれませんが、それでいても、
現状を打破するための良いツールがあれば、、、と願っています。
ツールに頼りっきりの開発現場からは良い品質のソフトウェアは
出来ないと言う方がいらっしゃるかもしれませんが……… じつは、いま、この時間も職場でがんばっていたりします（笑）
今ちょうどバグが取り終えたのですが、
ナカミは、PHPで組まれたシステムです。
これまたスパゲッティ状態のモノで…
仕様書はあっても、ちょっと、ね。
グチっぽくてすいません。ともかく、紹介してもらった
ツールがどうかを明日からさぐってみます。
もし、使ってみたことのある方、実際に業務で使われた
ことのある方、特に>>1で書いたツールと比べてどうなのか、を
教えてください。
おそらく、ワタシだけでなく、同じような途方もない労力を
虐げられている人がゴマンといるでしょうから…
ラクして開発したい、ビジネスロジックだけに集中したいと
願うのは贅沢な悩みじゃないとおもいます。 >>1
MacOSX使ってるんだったら
これを機にCGI開発環境でも作っちゃろか
と思ったんだけどなぁ。
Javaで作るかなぁ。emacsもいいけど、やっぱ
せっかくOSXなんだしAQUA使いたいわ。 >>11
マックは使っていないので、よくわかりません。
Webデザイナーがフォトショップの為に使いたいといっていたのですが、
トラブル防止（？）のために職場は全部WindowsやLinuxです。
MacOS Xもよくわかりません。BSDなコアを使ってるところはそそりますが… >>12
レスポンス早いにゃ。
Winならいろいろとあるのでわ？ 突然だが厨房ばっかりでウザイから終了するわ、ばいばい。
＝＝＝＝＝＝＝＝＝＝＝＝＝終了＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ >>1の気持ちはよくわかる...。
俺もこれからWebObjects評価するとこ。
自前APサーバー(ってmod_perlだ(藁)) の資産も捨てがたいんだけど
現状じゃどないもならん。 １です。
紹介されたWebObjectsについて、色々と調査をし、このツールを採用することになりました。
社員からはえー？アップルぅ？と、最初、拒否反応を示されたのですが、
ある会社の方にデモに来てもらったり、技術的な説明をしてもらい、
社員をうなずかせました。ワタシも最初は結構懐疑的でしたけど、
コーディング量の少なさ、全体的に簡潔な仕組み、運用環境の幅広さ、
そしてなんといっても７万円の安さなどから、このツールに決めました。
この板にもWebObjectsのスレがありますが、WebObjectsのデモをみていて判ったのが、
Servlet、JSP、EJBなどといった技術の為にコーディングをゴリゴリと
書く必要がないことや、複雑なSQLを埋め込む必要もない、画面設計がツールで
できるといった「開発者がラクをするためのツール」だと感じました。
情報不足が懸念されましたけど、セミナーや書籍、コンサルタントなどの
出費を考えても十分ペイできるであろうと判断しています。
（少なくとも今の人海戦術で発生するコストにくらべれば）
そういうわけで、あまり褒めまくってると、マック信者だと思われてしまいますが、
開発はWindows2000で行います。まぁ、がんばります。
２ヶ月後に始まるある企業の情報処理システムでこのツールを使うつもりです。 WebObjectsはアップルのツールであるということと、
独自のフレームワークを使うため、標準的なJava（J2EE）技術から
だいぶ離れてしまうことも懸念しました。それと、覚える時間も。
デモに来てくれた方の経験談では、フレームワークにあるクラス、メソッド数は
膨大な量だけど、実際に扱う数は少なく、一般的なJava言語の基本さえ
知っていれば特に問題はないと言われました。
確かに、JSP、Servlet、EJBといったアプリケーションサーバーの標準(?)
となりつつあるテクノロジーからかけ離れた世界になってしまいますが、
それらを駆使したシステムと同等かそれ以上の生産性、品質がクライアントに
納品できれば、極端な話、道具はなんでも良いと思っています。
仮に、WebObjectsを捨てて、他のツールに移行したとしても、
WebObjectsで培われてきた技術は他ツールでも十分通用するとも言われました。
イロイロと悩んだ末の結論でした。。
ここは２ｃｈなので色々いわれるかもしれませんが。。 Zopeってのがあるらしいが、これはどう？
ttp://www.zope.org
ttp://www.zope.ne.jp
ttp://www.zope.jp
この手のサイトにおきまりの煽り文句だけ見ていると、結構行けているような
かんじもするんだが。 はっきりいって、１の選択は正解。
ある意味、君はすごいよ。いいものを見抜ける力がある。 っていうか、WebObjectsは１に書いてある条件のすべてを
満たしてると思う。 わざとらしい、WebObject の関係者によるPRとしかおもえないすれだなぁ わざとらしい、WebObjects の関係者によるPRとしかおもえないすれだなぁ
うーん、なんか、おかしいなあ。。。書き込みがうまくいかんなあ >>22
スレたって5日で結論って、
よほど仕事が早いのか
出来レースだったのかのどちらかだよね。 そう言われるとそうだね。
WebObjects自体はいいものだと思うけど・・・。 >>24
残念ですが、私はWebObjectsの関係者ではありません。
>>25
そうですね、たしかに5日ほどで結論を出しました。場合によっては
>>24のようないわれ方をされても仕方ないかもしれません。が、
その5日のあいだ、他業務が薄かったこともあり、ずっとWebObjectsに
ついて調査したり、先に書いた外部の方に協力してもらったりと、
自分でいうのもなんですが、かなり積極的にやったと思っています。
もちろん、WebObjects以前は、WebLogicやWebSphereなども
同じぐらいかそれ以上の時間をかけて評価してきたつもりです。
ただ、誤解されたくはないのですが、WebObjectsに全力投球と
いうわけではなく、perl、php、それとWebSphereもこれまでどおり
使います。
つまり、超便利な道具が一つ増えたというものです。 ふーん、winでも動くんだ、WebObjectsって。 >>10
俺もそれは思ってWO導入したが、結局コーダーの問題であって、
うんこZopeとかでも十分実用性になると思う。
WOに逃げて（選択肢としてはいいと思うけど）も結局はデベロッパーの
組み方が変だとWO使っても（というか使うと）おかしくなるよ。
PHPで組める人間がいるのなら、その知識だけで十分使えるよ。
エンタープライズ級のシステムだって、PHPオンリーで組めちゃう。
PerlでもRubyでも。
既存の知識を生かしたほうがいいと個人的には思う。
Javaなんて使わなくてもね。
*自分は初代WOからのユーザーだよ。 >>34
>エンタープライズ級のシステムだって、PHPオンリーで組めちゃう。
>PerlでもRubyでも。
>既存の知識を生かしたほうがいいと個人的には思う。
>Javaなんて使わなくてもね。
まぁ、無理ではないが。
Javaならメソッド一発、とか、設定だけですむことを、時間かけて書く必要があるけどね。
もちろん最初はバグだらけで使い物にならない。
安定するまでの時間の無駄を許してくれるクライアントならいけるんじゃない？
というか、3年以上この業界にいて、未だに何のフレームワークも採用してないとこって、もう負け組確定だろ。 入力フォームとそれに関わる処理のコードの自動生成、とか、
表の扱いの単純化、が今のところ、フレームワークに必要用件で、
そのほか、アプリケーション固有のロジックのモジュール化（経理ソフトだったら、
絞込み用件のプラグイン化とか）が重要と思う。
>>35
納期までの日数の半分で完成させてしまうのを目標にやってるが、
Javaではしんどかった。（スキルが無いというだけかもしれないが）
よほどのすんごい作業がない限り、全部スクリプトで走らせてしまうよ。
ソース見られるのが困る場合は固めちゃう。 WOマンセーなヤシがこの板にはやけに多いが、流行っていない現実を
どう考える？
Appleの戦略がまずい、本来なら流行るはずだと言ってせっせと習得
してる人もいるのかもしれないが、
WOにいくら詳しくても現状では開発者としての市場価値は？？だぞ。
WOが先駆的なのは認めるけど、その先駆性はすぐにJ2EEや.NET
(またはPHPにも?)追いつかれるのではなかろうか。 >>40
いや、開発者の市場価値は流行に関係あるだろ。
自宅サーバで日曜プログラマならいいかもしれないが、メシの種と
して考えたらどうかな、と >>41
つくりあげるアプリにもよりけり。
あと、最近のWOのバージョンだと、よりJ2EEに近づいている。
独自性を持っているのはDBを制御するミドルウェアの部分ぐらいなもんかな。
J2EEも何らかのフレームワークをいれていれば、ほかじゃ通用しないという境地になるのと同じ。
別にWOだからどうこうというわけじゃない。WOとWebLogic両刀つかいより。 >>41
それもそうだが、既存のコードを全て置き換えたらいいだけの話では
ないだろうか。Java以外でコードは書くな！っていう環境なら話は別だが、
そうじゃなくてシステムを組んだりする場合には特に流行は気にしなくて
いいと思う。
それでやってきたけど問題点無かったし・・・ってのはまだまだヒヨコ？ >>43
実質本位でやればいいんじゃないか。
問題はそれは、いわゆる SI 企業にあるんじゃないか。
集中と選択が出来ている会社は「ウチは WO しか使わない」「Ruby のこれこれこういうフレームワークで開発と提案いたします」
みたいなことできるけど、ダメな企業は何でも屋でフレームワークもクソもなく、ダメなコードしか作らない。 ━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━― ∧＿∧
ﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
__∧＿∧_
|（ ＾＾ ）| ＜寝るぽ（＾＾）
|＼⌒⌒⌒＼
＼ |⌒⌒⌒~| 山崎渉
~￣￣￣￣ ∧＿∧ ∧＿∧
ﾋﾟｭ.ｰ （ ・３・） ( ＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
＝〔~∪￣￣￣∪￣￣〕
＝ ◎――――――◎ 山崎渉&ぼるじょあ (⌒V⌒)
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン xrea(というかレンタル鯖全般かも知れないけど)について質問です。
私はレンタル鯖を使ったことがないのですが(webコンテンツは自宅Linuxサーバがあるので
shellとか使えるから何でも出来てしまうのだが)今度使うことになったので教えてください。
xrea は php とか cgi がつかえるけど、php はそのまま
スクリプトが書かれた *.php を ftp で転送すればいいですが、
cgi(perl で書かれたものを想定)の場合、ftp で upload したあと、
$ chmod ugo+x hoge.cgi
とかしないといけないですよね。
xrea は shell が使えないので、これは ftp ソフトで、ファイルのパーミッションを
変えるのでしょうか？
また cgi の場合、ファイルの先頭に #!/usr/bin/perl とかインタプリタを指定しますが、
サーバによって、/usr/bin/perl なのか /usr/local/bin/perl なのか、パスが異なります。
普通はそのサーバにログインして、
$ which perl
/usr/local/bin/perl
などとしてインタプリタの位置を調べますが、xrea のばあい、コマンドインタプリタは
どうやって調べるのですが？ 適当に #!/usr/bin/perl などおいて ftp で upload して
アクセスしてみて、動いたら「あってたんだな」って確認するのでしょうか？
■ このスレッドは過去ログ倉庫に格納されています
