説明 : Description

Having a hard time getting mod_perl into your organization? We have collected some arguments you can use to convince your boss why the organization wants mod_perl.

あなたの組織に mod_perl を取り入れることに苦労していませんか ? 私たちはなぜその組織が mod_perl を必要とするのかあなたがあなたのボスを納得させるために使えるいくつかの論拠を収集しました.

You can contact the mod_perl advocacy list if you have any more questions, or good arguments you have used (any success-stories are also welcome to the docs-dev list).

あなたが他のクエスチョンをもっている, またはあなたが使ったことのあるグッドな論拠をもっている場合あなたは mod_perl advocacy list にコンタクトできます (何らかの成功事例は docs-dev list でも歓迎されます).

Also see Popular Perl Complaints and Myths.

(#a)Popular Perl Complaints and Myths (ポピュラーな Perl の不満と神話) も参照してください.

スケーラビリティとフレキシビリティについての考え : Thoughts about scalability and flexiblity

Your need for scalability and flexibility depends on what you need from your web site. If you only want a simple guest book or database gateway with no feature headroom, you can get away with any EASY_AND_FAST_TO_DEVELOP_TOOL (Exchange, MS IIS, Lotus Notes, etc).

あなたが必要とするスケーラビリティとフレキシビリティはあなたの web サイトであなたが何を必要とするかに依存します. もしあなたがシンプルなゲストブックやヘッドルーム (# 余裕のある, 多彩な) 機能のないデータベースゲートウェイのみを必要とするなら, あなたはなんらかの EASY_AND_FAST_TO_DEVELOP_TOOL (# 簡単ですぐに使える開発ツール) (Exchange, MS IIS, Lotus Notes, etc) をゲットすればよいです.

Experience shows that you will soon want more functionality, at which point you'll discover the limitations of these "easy" tools. Gradually, your boss will ask for increasing functionality and at some point you'll realize that the tool lacks flexibility and/or scalability. Then your boss will either buy another EASY_AND_FAST_TO_DEVELOP_WITH_TOOLS and repeat the process (with different unforseen problems), or you'll start investing time in learning how to use a powerful, flexible tool to make the long-term development cycle easier.

経験はあなたがすぐにより多くの機能を必要とすることを示し, その時点であなたはそれら "easy" ツールの制限を発見するのです. 次第に, あなたのボスが機能の向上を求めはじめるとあなたある時点でそのツールがフレキシビリティ and/or スケーラビリティに欠けていることに気がつくでしょう. その後はあなたのボスがいずれか別の EASY_AND_FAST_TO_DEVELOP_WITH_TOOLS を (これまでと違う予期しない問題とともに) 購入しそのプロセスを繰り返す, あるいは長期の開発サイクルをより簡単にするためにパワフルで, フレキシブルなツールをどのように使うかの学びに時間を費やすことをあなたが開始するでしょう.

If you and your company are serious about delivering flexible Internet functionality, do your homework. Then urge your boss to invest a little extra time and resources in choosing the right tool for the job. The extra quality and manageability of your site along with your ability to deliver new and improved functionality of high quality and in good time will prove the superiority of using solid flexible tools.

もしあなたとあなたの会社がフレキシブルなインターネットの機能の提供について真剣ならば, あなたの宿題をしてください. それから仕事のための正しいツールを選択するために少し余分な時間とリソースを費やすようにあなたのボスを促してください. あなたのサイトのエクストラなクオリティと管理性とともにあなたが新しくて改善されたハイクオリティな機能をグッドなタイミングで提供すればソリッドでフレキシブルなツールを使うことの優位性が証明されるでしょう.

ボス, 開発者それからアドボカシー : The boss, the developer and advocay

Each developer has a boss who participates in the decision-making process. Remember that the boss considers input from sales people, developers, the media and associates before handing down large decisions. Of course, results count! A sales brochure makes very little impact compared to a working demonstration, and demonstrations of company-specific and developer-specific results count for a lot!

各開発者は意思決定プロセスに関与するボスをもちます. ボスは大きな決断を下すまえにセールス担当, 開発者, メディアや同僚からのインプットを考慮することを忘れないでください. もちろん, 成果が重要です. セールスブローシャ (# パンフレット) は機能するデモンストレーションと比較してとても少ないインパクトにしかならず, 会社固有であり開発者固有のデモンストレーションの結果は大いに価値があります.

Personally, when I discovered mod_perl I did a lot of testing and coding at home and at work. Once I had a working heavy application, I came to my boss with two URLs - one for the plain CGI server and the other for the mod_perl-enabled server. It took about 30 secs for my boss to say: `Go with it'. Of course since then I have had to provide all the support for other developers, which is why I took time to learn it in first place (and why this guide was created!).

個人的に, 私が mod_perl を見つけたとき私は自宅や職場で多くのテストとコーディングを行いました. 私が機能するヘビーなアプリケーションをもつことができたとき, 私は 2 つの URL とともに私のボスのもとへ向かいました - 1 つはプレーンな CGI サーバでもうひとつは mod_perl を有効化したサーバです. 私のボスがこれをいうまで 30 秒ほどでした: `それでいこう'. もちろんそれ以来私は他の開発者のためのすべてのサポートを提供しなければならず, それが理由で私は最初の時点でそれ (# mod_perl) を学ぶための時間をとったのです (そしてこれがこのガイドが作られた理由です !).

Chances are that if you've done your homework, learnt the tools and can deliver results, you'll have a successful project. If you convince your boss to try a tool that you don't know very well, your results may suffer. If your boss follows your development process closely and sees that your progress is much worse than expected, you might be told to "forget it" and mod_perl might not get a second chance.

もしあなたがあなたのホームワークを終わらせて, そのツールを学び成果をもたらせれば, おそらくあなたは成功するプロジェクトをもつことになるでしょう. もしあなたがあなたがよく知らないツールにトライするようにあなたのボスを説得するなら, あなたの結果は悲惨になるでしょう. あなたのボスがあなたの開発プロセスを注意深くフォローしていてあなたの進捗が予想よりもかなり悪ければ, あなたは "それを忘れろ" といわれるでしょうし mod_perl が 2 度目のチャンスを得ることはないかもしれません.

Advocacy is a great thing for the open-source software movement, but it's best done quietly until you have confidence that you can show productivity. If you can demonstrate to your boss a heavy CGI which is running much faster under mod_perl, that may be a strong argument for further evaluation. Your company may even sponsor a portion of your learning process.

アドボカシー (# 主張) はオープンソースソフトウェアムーブメントにとってグレートなものですが, それはあなたがプロダクティビティ (# 生産性) を示せるとあなたが確信をもつまでは静かに行われることがベストです. もしあなたが mod_perl のもとではるかに高速に走るヘビーな CGI をあなたのボスにデモンストレーションすることができれば, それはさらなる評価のための強力な論拠になるでしょう. あなたの会社はあなたの学習プロセスの一部の後援さえするかもしれません.

Learn the technology by working on sample projects. Learn how to support yourself and learn how to get support from the community; then advocate your ideas to your boss. Then you'll have the knowledge; your company will have the benefit; and mod_perl will have the reputation it deserves.

サンプルプロジェクトに取り組むことによってテクノロジを学んでください. 自分自身をどのようにサポートするかを学びどのようにしてコミュニティからのサポートを得るかを学んでください; それからあなたのアイデアをあなたのボスにアドボケイト (# 主張) します. そうすればあなたは知識をもっていて; あなたの会社はベネフィットをもち; そして mod_perl はそれにふさわしい名声をもっているでしょう.

slashdot.org における perl/CGI ディスカッションのサマリ : A summary of perl/CGI discussion at slashdot.org

Well, there was a nice discussion of merits of Perl in CGI world. I took the time to summarize this thread, so here is what I've got:

さて, CGI ワールドにおける Perl のメリットについてナイスな議論がありました. 私は時間をつかってこのスレッドをサマライズ (# 要約) しました, こちらが私がもっているものです:

Perl Domination in CGI Programming? http://slashdot.org/askslashdot/99/10/20/1246241.shtml

CGI プログラミングで優勢な Perl ? http://slashdot.org/askslashdot/99/10/20/1246241.shtml

• 
  

  Perl is cool and fun to code with.

  
  Perl はクールでありコーディングで楽しい.
  


• 
  

  Perl is very fast to develop with.

  
  Perl は開発でとても速い.
  


• 
  

  Perl is even faster to develop with if you know what CPAN is. :)

  
  Perl はあなたが CPAN が何かを知っていると開発がさらに速い. :)
  


• 
  

  Math intensive code and other stuff which is faster in C/C++, can be plugged into Perl with XS/SWIG and may be used transparently by Perl programmers.

  
  C/C++ でより高速な数学インテンシブ (# 数学に集中した) なコードや他のものは, XS/SWIG で Perl に接続できて Perl プログラマによって透過的に使われることがでる.
  


• 
  

  Most CGI applications do text processing, at which Perl excels

  
  ほとんどの CGI アプリケーションはテキスト処理を行い, それは Perl が優れているところ
  


• 
  

  Forking and loading (unless the code is shared) of C/C++ CGI programs produces an overhead.

  
  C/C++ プログラムのフォークとロードは (コードがシェアされていない場合) オーバーヘッドを生成する.
  


• 
  

  Except for Intranets, bandwidth is usually a bigger bottleneck than Perl performance, although this might change in the future.

  
  イントラネットを除き, 帯域幅は通常 Perl のパフォーマンスよりも大きなボトルネック, だけどこれは将来変わるはず.
  


• 
  

  For database driven applications, the database itself is a bottleneck. Lots of posts talk about latency vs throughput.

  
  データベース駆動のアプリケーションでは, データベース自身がボトルネック. 多くの投稿がレイテンシ vs スループットについてトークしている.
  


• 
  

  mod_perl, FastCGI, Velocigen and PerlEx all give good performance gains over plain mod_cgi.

  
  mod_perl, FastCGI, Velocigen それから PerlEx はすべてプレーンな mod_cgi を超えるグッドなパフォーマンスゲインを与える.
  


• 
  

  Other light alternatives to Perl and its derivatives which have been mentioned: PHP, Python.

  
  言及されている Perl とその派生に対する他のライトな代替手段: PHP, Python.
  


• 
  

  There were almost no voices from users of M$ and similar technologies, I guess that's because they don't read http://slashdot.org :)

  
  M$ や同様のテクノロジのユーザからの声はほとんどありません, 私はそれは彼らが http://slashdot.org を読んでいないからだと推測します :)
  


• 
  

  Many said that in many people's minds: 'CGI' eq 'Perl'

  
  多くの人々は心のなかでいっています: 'CGI' イコール 'Perl'
  

メンテナ : Maintainers

Maintainer is the person(s) you should contact with updates, corrections and patches.

• Stas Bekman [http://stason.org/]

作者 : Authors

• Stas Bekman [http://stason.org/]

Only the major authors are listed above. For contributors see the Changes file.

NEXT

次回は、「 Documentation / General Documentation / Part V: mod_perl Advocacy / Popular Perl Complaints and Myths 」を「 mod_perl 」公式サイト (https://perl.apache.org/index.html) より確認します。


参考情報は書籍「 続・初めての Perl 改訂版 」, 「 Effective Perl 第 2 版 」を中心に perldoc, Wikipedia および各 Web サイト。それと詳しい先輩。

目次 - Perl Index