質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.52%

  • Ruby

    9414questions

    Rubyはプログラミング言語のひとつで、オープンソース、オブジェクト指向のプログラミング開発に対応しています。

  • Perl

    495questions

    Perlは多目的に使用される実用性が高い動的プログラミング言語のひとつです。

  • Framework

    141questions

    Frameworkは、アプリケーションソフトを開発する際に、一般的な機能をより簡単に、より早く完了させる事を目的とした、ソフトウェアやライブラリのセットを指します。開発にフレームワークを使用する事で、追加で必要となる機能だけを開発するだけで済む為、開発効率の向上が見込めます。

WEBアプリケーションフレームワークについて

解決済

回答 8

投稿

  • 評価
  • クリップ 2
  • VIEW 1,081

yoichiro_ito

score 95

普段は、Perl や Ruby でWEBアプリを書いています。
CGIだったり、テンプレートエンジンを使ったりしています。
しかしながら、 最近はWEBアプリケーションフレームワークを利用したことがありません。
大昔(10年以上)、Javaのフレームワーク(ベンダ製)をプロジェクトで採用し、生き地獄に堕ちた経験からか、懐疑的です。
Ruby on Rails , Mojolicious , Catalyst , Lotus などは、細かな制御を挿し込んだり、Viewを変更したり、柔軟に開発(カスタマイズ)できるものでしょうか?
また、それほどに高速開発が可能なのでしょうか?
まずはやってみなさい! というお叱りを賜りそうですが、ご経験などうかがえましたら、幸いです。
次の仕事は、社内の FAQサイトを構築することになります。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 8

checkベストアンサー

+3

私見です。


Ruby on Rails(以下RoR)のようなフルスタックフレームワークは「細かな制御を挿し込んだり、Viewを変更したり、柔軟に開発(カスタマイズ)」というのは苦手です。特にRoRのような「設定より規約」を重視するフレームワークは、細かい所を変えようとすると途端に面倒になります。もし、これまでのフルスクラッチのように自由に思い通りに動かしたいと思うのであれば、フルスタックフレームワークは邪魔者以外の何者でもありません。あれもできない、これもできない、となって、結局全部作ってしまうのがオチです。

しかし、これは見方を変えると悪いことではありません。逆に、型どおりの、RoRで言うなら文字通りレールに沿ったアプリであれば、何も変更する必要がないとも言えます。あるデータを、ただ表にするだけ、閲覧するだけ、入力するだけ、それでいて、名前やURLにこだわりがなければ、きっと、恐ろしく速く、慣れている人であれば、一晩もかからずに作れてしまいます。

そう、高速開発ができるのはあくまで型に嵌まっているときだけなのです。それから外れるようなイレギュラーな処理が多すぎるようなWebアプリケーションにフルスタックフレームワークを採用するのは愚かです。でも、ほとんどのWebアプリケーション、例えばこのteratailなんかも型にはまった開発ができます。なぜなら、これらのフレームワークは多くのWebアプリケーションの最大公約数になるように作られているからです。だからこそ、フレームワークは有用であり、多くで採用されているのです。

これらフルスタックフレームワークを採用する場合は、設計の考え方を変える必要があります。Webアプリケーションをフレームワークにあてはめるのではなく、フレームワークにWebアプリケーションをあてはめるのです。フレームワークを設計にあわせてカスタマイズしようとしてはいけません。フレームワークにあわせて設計していきます。そうすれば、そもそもイレギュラーな事は起こりえません。フレームワークでできないことや、やたら難しい作り込みが必要な部分も出てきません。

でも、どうしても当てはまらない場合があります。そういうときにフルスタックではないフレームワーク(マイクロフレームワーク(microfarmework)とかシンフレームワーク(こっちは造語っぽい)とかいわれます)を使うという手もあります。RoRの対比でSinatraがわかりやすい事例として出されます。Sinatraは、RoRのようにコマンド一つで、MVC全部用意なんてしてくれません。ルーティングを行う最低限の土台だけです。どういうルーティングなのか、何をビューにするか、データはどう用意するかも全て細かく指定してあげる必要があります。でも、逆に言うと、標準的なMVCに縛られる必要もなくなります。より柔軟で、細かい制御が初めから可能です。というより、初めから細かい制御をしてあげる必要があります。

これはどちらが優れているかとか優れていないとかいうモノではありません。作るモノによるからです。他のフレームワークも同様です。フレームワークにも特色があり、RoRのように型にはまったモノから、Sinatraのように柔軟性があるものまで様々で、そのレベルや度合いもそれぞれです。良いところもあれば悪いところもありますが、難しいところは、一度は触らないとそれぞれの特色がなかなか見えてこないと言ったところでしょうか。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/07/19 23:50

    ご回答ありがとうございます。
    WEBアプリケーションを中心に考えるのではなく、フレームワークを中心に考えるのですね。
    わたしの担当している業務(WEBアプリケーション)はもう本当に極端で、
    (1) きっちり提携的な業務
    (2) ETLかEAIかのようなシステムを複合的に連携する業務
    になります。
    いままでは(2)に割合が高かったのですが、これからは(1)がメインのミッションになりそうです。
    Railsを学習していきたい、と思います。

    キャンセル

+3

Ruby on Rails  についてだけ述べます。

... 細かな制御を挿し込んだり、Viewを変更したり、柔軟に開発(カスタマイズ)できるものでしょうか? ...

はい、どれも可能です。
ただし、Rails のルールの中でおこなうならという条件がつきます。
Rails のルールに沿わないような変更をしようとすると、手間もかかるし、バグも入り込みやすくなります。

フレームワークや、各種ライブリーを使う一番の利点は、先人のノウハウを、詳細を知ることなく利用できることです。
DBの扱いやセキュリティ関係のことは、一から勉強していたり、下手に自作すると性能問題やセキュリティ・ホールが入りこみがちです。

まずは、なにか1つ実際にチュートリアルを終了させてみると良いと思います。(20 時間から 100 時間程度をかけて)

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/07/19 23:26

    ご回答ありがとうございます。
    > はい、どれも可能です。
    実はこの部分をもっとも懸念しておりました。
    Railsで対応可能なのですね。
    まずはそれなりの時間をかけて学習(チュートリアル、実装)してみます。

    キャンセル

+2

個人的な偏見ですが…
ある程度の不自由さとひきかえに、考えることを少なくするのが
フレームワークなのかなって思ってます。
もちろんフレームワークも進化しているでしょうし、
個々のフレームワークによっても違ってくるでしょう。
ちなみに、高速開発ができるのは、フレームワークに
利用者のアタマが馴染んでからの話ではないかなあ、と。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/07/19 22:11

    > 考えることを少なくする
    なるほど、そういうことなんですね。
    ありがとうございます。
    まずは、1つでもフレームワークを使いこんでみることにします。

    キャンセル

  • 2016/07/19 22:20

    (・∀・)b

    キャンセル

+2

こんばんは

生き地獄に堕ちた経験からか、懐疑的です。 

認知バイアスってやつですね。

私も日本製のフレームワークには懐疑的なのですが、これも認知バイアスですね ^_^;

フレームワークというのはどちらかというと柔軟性とは反対にあるように思います。

全員が天才的なひとばっかり集まってて全員の考え方が透過的に通じていれば
フレームワークなんて要らないと思います。

ある程度のプロジェクトでいろいろなレベルの人が集まって実装するときに
それぞれが好きに実装してしまっては、どのような構成になっているのか分からなくなってしまうとかを防ぐ。

高速に開発できるかどうかは、フレームワークの学習コストにもよるので一概には言えないと思いますが、
ある程度、共有知識としてみんなが持っていれば加速するのかもしれません。
(その意味で内製FWは、あまり嬉しくないですね)

他には、セキュリティ対策とかがされているので、その辺り考える必要がないとか、
本来のロジックに集中できるというメリットがあると思います。

なので、私は一人で作る時もフレームワーク使います。
ですが、フルスタックフレームワークと呼ばれるものは学習コストが高い気がして使いませんが。

今時素で書くのは、C言語があるのにアセンブラで頑張ってる感じもしないでもないですけどね。

偏見ぽい書き方ですが、そうじゃなくて、能力の高い人はその方がいいのかも知れませんが、
私は能力低いの自覚しているので人が考えてくれる仕組みがあるのであればそれに乗っかりたいのです^_^;

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/07/19 22:37

    ご回答ありがとうございます。
    ある程度の縛りがあるため、チーム開発において、品質が均一化され、各自のコードのクセ(偏り)が低減される、ということですね。

    キャンセル

+2

Webフレームワークが高速開発のために作られているのは間違いないですが、
フレームワークによって、何が得意か不得意かが違いますので、
全てのケースに対応できる万能のものと考えてはいけません。

初心者でもある程度カンタンにWebアプリが作れる、という種類のものなら、初心者プログラマーが小さくて単純なWebアプリを作るのだったら高速に作れるのはほぼ確実でしょう。
しかし、特殊な要件を含んだWebアプリの構築には柔軟なカスタマイズが可能でないと難しかったりしますので、それがしにくいフレームワークでは、高速に開発できないかもしれません。

とはいえ、最近のオープンソースのフレームワークは、種類も豊富ですし、自動でできることも多くなってきましたので、10年前のようなことにはならないとは思います。
ただ、便利な機能があったとしても、フレームワークに習熟することは必要になりますけどね。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/07/19 22:32

    ご回答ありがとうございます。
    フレームワークにも得意、不得意があるのですね。
    いろいろ、試行錯誤してみます。

    キャンセル

  • 2016/07/19 22:41

    補足です。

    フレームワークも(特に同じ言語のものなら)独自性が求められるので、
    機能によっては、すべてのフレームワークでほぼ同じことが実現できるものもあれば、
    あるフレームワークでは実現できない機能もあります。
    (例えば、自動生成機能や、ある部分のカスタマイズ機能、などなど)

    結果として、得意・不得意な面が出てくるわけです。

    キャンセル

  • 2016/07/19 22:51

    なるほど、そうですか。
    やりたいこと...といいますか、まずは眼の前の仕事(『FAQサイト』)に適用できるフレームワーク( + 私の書ける言語( Perl, Ruby , PHP)) で探してみます。
    ありがとうございます。

    キャンセル

+2

個人的な意見ですが開発者側(フレームワークの利用者)の観点から見ると、
いずれのフレームワークも最初の学習コストは避けられないし、慣れるまでは時間を取られます。
ただし要領が分かると作成パターンが明確化するので開発速度は上がります。
ただしイレギュラーなことを実現したいなどとなると小回りが効かないケースもしばしばですが。

こっちはかなり想像も入っておりますがフレームワーク導入側の視点だと、
保守性が向上するというのが最大のメリットではないでしょうか。
フレームワークでうまく縛りを与えることにより、各開発者間の実装のばらつきをある程度は防止できたりしますので。
(上記はコーディング規約(機能作成のいろは)などを事前決めておくとある程度効果が見込めるかも…)

明後日なこと言ってたらすいません^^;

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/07/19 22:46

    ご回答ありがとうございます。
    > 保守性が向上するというのが最大のメリット
    わたしは中小小売業の社内プログラマですので、このメリットはありがたいです。
    転職(^^; しない限り、自身の書いたコード(仕組み)に追い掛け回されますので。
    実装のばらつきが低減するというのもいいですね。
    決してヒトのことは言えないのですが『何をしているのだろうか? このコードは!』と思う実装にたくさん出会いますので。

    キャンセル

+2

フレームワークとは枠組みなので、
自由度と効率性がトレードオフの関係になっています。

つまり定型的なサイトほど効率的、高速に作れます。
たとえばブログとか決まり切ったジャンルですね。

逆にたとえば、UIなど凝りまくった個性的なサイトを
作ろうとすると、相性が悪い場合もあるでしょう。
それこそフルFlashで作っていたようなサイトとか。

またフレームワークの学習コストもバカにならず、
言語を覚えるのと変わらないコストがかかります。
ただし、定型的なサイトを作り続ければ元が取れます。

一方「FAQサイト」に対して、ユーザはUIに近い側の個性よりも
情報を求めて見るので(質問掲示板とかもそうでしょう)、
フレームワークがわりと向いてるジャンルだとは思います。

けっきょく、フレームワークも取捨選択で、
自由度、効率性、学習コスト、ユーザの需要……、
どのファクターをどれくらい重視するかだと考えます。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/07/19 22:59

    ご回答ありがとうございます。
    わたしの担当している業務(ヘルプデスク、カスタマサポート)では、定型的なサイトがメイン(といいますか、すべて)ですので、これ(FAQサイト)を機になにか 1つフレームワークに取り組んでみようと思います。
    また、意外に学習コストがかかるとのこと、了解いたしました。

    キャンセル

0

phpMyFAQ 2.9

FAQに特化したCMSです。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/07/19 22:29

    ご紹介ありがとうございます。
    取り急ぎ、インストールしてみます。

    キャンセル

  • 2016/07/19 22:32 編集

    要件を満たすのであれば出来合いのものを使うというのもアリですね。

    キャンセル

  • 2016/07/19 22:33

    インストールしなくても、DEMOがあるようですよ

    キャンセル

  • 2016/07/19 22:39

    ありがとうございます。
    トップページに目立つ色でありました。
    お手数をおかけいたしました。

    キャンセル

同じタグがついた質問を見る

  • Ruby

    9414questions

    Rubyはプログラミング言語のひとつで、オープンソース、オブジェクト指向のプログラミング開発に対応しています。

  • Perl

    495questions

    Perlは多目的に使用される実用性が高い動的プログラミング言語のひとつです。

  • Framework

    141questions

    Frameworkは、アプリケーションソフトを開発する際に、一般的な機能をより簡単に、より早く完了させる事を目的とした、ソフトウェアやライブラリのセットを指します。開発にフレームワークを使用する事で、追加で必要となる機能だけを開発するだけで済む為、開発効率の向上が見込めます。