q.hatena.ne.jp/1297007982 の続きです。
様々な、お手厳しい、しかし極めて有益な意見を多数頂戴いたしました。
皆様、有難う存じます。
しかし、やはり既製CMSの改造では無理のように思われます。
・はてな的なポイントシステム、特定認証局、お仕事斡旋、ナレッジベースなどを
統一したシステムで運用したい
・システムに対する低水準の理解を要する
などの理由です。
「車輪の再発明」の愚を犯すだろう、とのご意見も頂戴しましたが、
私個人の性質として、
「帰納よりも、演繹的な学習・実践から得るもののほうが、結局遥かに大」
というものがあり、
これもあって、やはり一から作りたいと思います。
HTML、サーバサイドJava、PHP、MySQLなどで。
力が及ばない領域は、厳格なI/O仕様の元、外注しようと思います。
そこで、皆様に引き続き質問です。
・Javaのフレームワークは何がよいでしょう？ 特にHTMLのインターフェイス関係が充実しているものがよいです。
・それでもやはり既製のものから入っていった方がよいだろうなど、
その他ご意見を頂戴できるとすれば、ご自由な形式・テーマで、是非ご忌憚なきご意見を下さいませ。
よろしくお願い申し上げます。
ベストアンサー
-
kent0608
満足100pt
前回の質問でコメントした者です。メッセージありがとうございました。わざわざポイントも添付していただいたようで恐縮です。
さて、前回のコメントにもあるように、スタートアップの資金不足の問題を解決するためのプラットフォームとしてGoogle App Engine / Java とそのWebアプリケーションフレームワーク、Slim3を推薦しましたが、MySQLのようなRDBMSにはないデメリット（及びメリット）がGoogle App EngineのDatastoreにはありますので、その点を抑える必要があります。
（参考記事）
http://www.atmarkit.co.jp/fjava/rensai4/bigtable01/01.html
特に複雑な検索や集計処理が苦手です。（そのトレードオフとして高いスケーラビリティを持っています）
開発するアプリケーションの要件によっては適さないことがありますので、その場合は
他の回答者様もご指摘のStruts（またはそれをベースにしたSAStruts）とMySQLのようなRDBMS（及びS2JDBC等のO/Rマッパー）を使われるほうが良いと思います。
※素のStrutsは生産性が低いので、個人的にはStrutsの問題点を改良したSAStrusを推します。
とはいえ、事業として成功するためには増減するトラフィックを柔軟に処理できる仕組みづくりが必要不可欠です。
この点において、GAE/Jは低い追加コストでスケールするシステムとなっているため、対応が非常に楽です。
（また前回のコメントにある通り、インフラに対する初期投資が0円であることも魅力です）
開発で苦労するか、運用で苦労するか、その選択が大事ですよね。
ちなみに広く一般に普及しているWebサービスは、開発よりも運用で苦労しています。（そして多額の人的、物的投資をしています）
利用範囲が決まりきっている、イントラ向け受託開発であればSAStruts＆S2JDBC（またはStrutsとその派生）
不特定多数のユーザが利用する、オープンなWebアプリケーション開発であればGAE/J(Slim3)が良いですね。
（Slim3参考）
http://sites.google.com/site/slim3documentja/
（Datastoreの理解に）
-
Web-Production
-
Web-Productionその他の回答
この質問へのコメント
質問の情報
- 登録日時
- 2011-02-11 07:19:45
- 終了日時
- 2011-02-17 04:15:02
- 回答条件
- 1人5回まで
この質問のカテゴリ
この質問に含まれるキーワード
人気の質問
-
この英文どうなってますか？ The boy seemed to be waiting for his mother to come.（その少年は母親が来…
匿名質問者
1
1
-
不定詞の形容詞的用法らしいんですけど、副詞的用法と書いたら✖️ですか？ I want to buy a book to read …匿名質問者11
-
日向陽葵という○V女優が好きなのですが似ている○V女優はいますか匿名質問者
-
共通テストで使われるプログラミング言語は共通テスト特有の言語と聞いたのですが、受験勉強で身につけたプ…匿名質問者1
-
内定してほしいポケモンはいますか？匿名質問者
私の時はまだ初版でしたｗ。
PHP はフレームワークもありますが、小規模のものでしたので明確な MVC にせず、
各画面構成と、データ管理クラスだけで実装したので、ちょっと趣旨とは異なります。
Struts は普及しただけあって、いろいろなことができますが、JSP を使いこなせる
ようになるまでと、バリデーションやリソース管理、ログ管理などを覚えるまでが
一山かもしれません。
その他のフレームワークは存じませんが、同様の機能はあると思います。
SQL は最低限の操作（SELECT、INSERT、UPDATE、DELETE）は覚えないと、始まりません。
ストアード・プロシージャまで利用できると、便利な局面も多いです。
JavaScript も、XML や DOM の操作ができる程度の知識は習得された方がよいでしょう。
サーバに問い合わせなくてもクライアント側での処理で片付くことは、JavaScript で
済ませてしまった方がパフォーマンス的には快適なことが多いです。
いろいろなご助言、ありがとう存じます。先行きのめあてができ、大変たすかります。
Tomcat + Java + Struts と Google App Engine/J with Slim3 と、どちらがよいと思われますか？ Slim3に関する書籍が来ましたので、呼んでみると、「これは App Engine の規制でできない」などの記述があり、少し不安です。
とにかく、これまでのご助言だけでも、大変参考になりました。ありがとうございます。
調べてみたら Google だけでなく Amazon や Yahoo など多くがこういったサービスを提供
しているのですね。すっかり時代遅れになっています^^;;。
kent0608 さんが書いていますが、一つの選択ポイントはやはり利用形態だと思います。
でも最終的にはこれ以外にも開発・評価環境、コスト、パフォーマンス、保守性 などに
対するメリット・デメリットを考え、Web-Production さんにとってのベストをご自身で
判断するしかないと思います。
既に候補が2つまでに絞れているなら、両方でやってみてはどうですか？
実際に使ってみないと分からないことは多いですし、両方を使ってみることでそれぞれの
利点・欠点 がより具体的に理解できると思います。
ただ GAE で使用される GQL は JOIN をサポートしない SQL のサブセットのようなので、
SQL に関しては別途きちんと習得されておいた方が良いとは思います。
＞SQL に関しては……習得されておいた方が良い
ありがとうございます。join がないとすれば、なにか他の同等のクエリーがあるのでしょうか。"GQL" ですね。ありがとうございます。
Google のデータベースには、"Fusion Tables" と "Big Table(s?)" とがあるようで、関係が良くわかりません。その辺、自分でよく調べてみます。何か、Google は、「Fusion Tables はこれまでのデータベースの観念を覆すような画期的なもの」という旨のステートメントをしていますが、どう画期的なのかは、いろいろなページを見てもわかりません……。MS Access しか低水準で扱えない私には、わからないのでしょうか。
Slim3であればSlim3 Datastoreを使ってDatastoreに対するクエリを組み立てます。
http://sites.google.com/site/slim3documentja/documents/slim3-datastore
複雑なクエリ（JOINを駆使しなければならないようなもの）を必要とする場合、
そもそも設計がDatasotre向けでは無いことの証明ですので、JOINの代替案を探すのではなく
設計段階からやり直します。（正規化しない等）
それでも実現できないようなものであれば、素直にスケールしにくい代わりに柔軟性の高いRDBMSのシステムに移行するのが良いでしょう。ケースバイケースです。
この辺りはいろいろ情報を検索して身た方が良いかと思いますが、
http://code.google.com/intl/ja/appengine/docs/python/datastore/gqlreference.html
要は GQL は GAE でパフォーマンスを発揮できるよう、必要な機能に限定したサブセットだ
というのが私の認識です。
先のコメントは、実際の開発で使う使わないは別にしても、SQL を習得しておいた方が
（少なくとも現時点での主流である）データベースを理解するのに有用であるという、
見地からです。
知っておいた方が良いのは SQL というよりは、データベースの正規化などのDB一般の概念
といった方が良いでしょうか。
ベタなテーブルですべての項目を管理するというのは、私の感覚からすれば気持ちが悪い
設計です（時代遅れかもしれませんが）。
まぁ、目的さえ達成できれば余計な知識は不要というのも一つの考え方かもしれません。
私のコメントや回答は、エンジニアとしては幅広い知識を持っていたほうが良いのでは
ないかという個人的な意見ですので、そのあたりはご自身のスタンスと照らし合わせて
取捨選択の上、参考にしてください。
ありがとうございます！ よくわかりました。
＞Mook様
＞べたなテーブルで…気持ちが悪い
私も少しそういう感覚がありますが、一方で、シンプル極まりないものでシステムを作るのも、信頼性が高く良いのではないかとも思います。
いろいろ、ありがとうございます。
質問者でございます。
http://q.hatena.ne.jp/1297883269 に新しい質問を書きましたので、
もしよろしければ、ひきつづきご意見を頂戴できればと存じます。
よろしくお願い申し上げます。