GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Craig Wickesser , 翻訳者 沼田 暁子 投稿日 2008年1月30日
Sunにお願いしたいのは、JRubyのサポートをやめて欲しいということです。時間の無駄だと思います。そちらにかける費用をGroovyに回して下さい。GroovyのシンタックスはJavaと非常に親和性が高いものです。また、言語の発展を進めて欲しいと思いますし、Javaのシンタックスを壊すのはやめて下さい。それから、GroovyのまともなIDEツールを作って欲しいです。また、Javaを頻繁にいじるのは止めてください。Rickは、彼がSunにリクエストする理由をいくつか述べているが、シンタックスの問題も含まれている。
Rickは、シンタックスに加えてプログラミング言語の人気も考慮するべきだと述べ、JavaのほうがRubyよりもずっと人気があることを示すグラフを載せている。SunはJRubyを通してRubyに投資しています。残念です。GroovyはJavaに非常によく似ていて、とても始めやすい言語です。開発者がシンタックスのせいで苛立つこともありません。
Rubyに多額の投資をするべきではないもう一つの理由がこのグラフです。グラフの色の区別がわかりにくい方のために言っておくと、Rubyの人気は完全に最下位なんです。
Rubyは完全に最下位です。大変革が起きそうだったとしたら、すでに起こっていたでしょう。Rubyはちょっと古く不成功に終わると思います。そう思いませんか?
Java はC++やCに似ているから人気があります。C++はCに似ているから人気があります。C#はJavaに似ているから人気があります。このパターンを理解してください。Gosling氏のリードに従い、そしてGroovyのきちんとしたサポート(コードの完成やリファクタリング等)を追加して欲しいと思います。新しい言語機能がメインストリームになったときは/もしなったら、それからJavaに追加して下さい(あるいは、それが理にかなったものでなければ、追加しないで下さい)。
私は、我々には選択の余地があるべきだと思っています。ですから、JRubyの開発をやめるように依頼するのは私にとっては不当なことです。誤解しないで欲しいのですが、私はまだJRubyが好きではないですし、現時点ではGroovyを使っています。でも、JRubyもScalaも残しておいて欲しいのです。選択肢があるということは素晴らしいことです。
Michael Galpin氏(source)は、議論を異なる観点から見て投稿しています。特に、Scalaに投資することに価値がある理由を一つ述べています。
制御の抽象化を備えた言語には大きな可能性があります。Scalaはまさにそういった言語です。アクタ・モデルや何も共有しない(shared nothing)モデル、並列コンピューティングのためのメッセージベースの設計といったものの実装が、Scalaでは可能なのです。これはJavaではできません。Groobyだったら、多少はできますが、扱いにくいものになるでしょう。その理由は単純です。例えばクロージャを呼び出すメソッドを呼び出すオブジェクトがあったとして、Scalaでは、クロージャからオブジェクトに制御を戻すことが可能ですが、Groovyではメソッドにしか戻せません。 Groovyに組み込まれている特別な制御構造は、よくても制御の抽象化のいくつかの面を扱いにくくするでしょう。ブロガーのOla Bini氏(source)もRick Hightower氏とは意見が異なる。
私はJRubyは重要だと思います。というのは、Javaと同じ環境で実行できるのですが、Javaで発生する問題が起こらないからです。Ola氏は、彼がJavaに存在すると思っている問題点や、何故JRubyがよりよい選択であるのかを説明している。さらに、Michael Galpin氏はSunがJRubyに関心を持っている理由をこう述べている。
Sunは、新しい言語やプラットフォームを導入し、それを産業界のデファクト・スタンダードにすることがどれだけのものがかかるかを知っています。それは非常に困難で費用のかかることです。彼らは一度経験していますが、非常にコストがかかりました。Javaはずっと頂点に立ちつづけることはできません。彼らは、もう同じような苦労はしたくないと思っています。けれども、JRubyでRailsを取り込むことができれば、Railsアプリケーションをデプロイする最善の方法がJRubyとなり、今度は何もしなくても「頂点に立ちつづける」ことができるでしょう。彼らは、Railsコミュニティーがやってくれるのに任せているのです。
SunのJRuby支援に加え、NetBeans IDEのJRubyサポート機能の開発も行われている。その一方では、NetBeansでGroovyやGrailsをサポートする機能の開発も活発に行われていることにも言及しておかなければならない。実際、Martin Adamek氏(source)は、NetBeansでGroovyやGrailsをサポートするアップデートをブログ(source)で提供している。
さて、皆さんはどうお考えだろうか。JVMに様々な言語をサポートする余地はあるのだろうか?SunはGroovyを支援し、開発やツールのサポートを強化するべきなのだろうか?
原文はこちらです:http://www.infoq.com/news/2008/01/sun_drop_jruby
【豆蔵】大好評のため、Jenkins講座を追加開催致します!Jenkins作者の川口氏が講師です。
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信