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

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

新規登録して質問してみよう
ただいま回答率
85.50%
Perl

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

Ruby

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

Framework

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

Q&A

解決済

8回答

2582閲覧

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

yoichiro_ito

総合スコア103

Perl

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

Ruby

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

Framework

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

0グッド

2クリップ

投稿2016/07/19 12:55

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

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

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

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

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答8

0

ベストアンサー

私見です。


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 14:23

raccy

総合スコア21733

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

yoichiro_ito

2016/07/19 14:50

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

0

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

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

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

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

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

投稿2016/07/19 14:07

katoy

総合スコア22324

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

yoichiro_ito

2016/07/19 14:26

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

0

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

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

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

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

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

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

投稿2016/07/19 13:51

LLman

総合スコア5592

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

yoichiro_ito

2016/07/19 13:59

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

0

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

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

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

投稿2016/07/19 13:32

Panzer_vor

総合スコア1636

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

yoichiro_ito

2016/07/19 13:46

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

0

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

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

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

投稿2016/07/19 13:27

argius

総合スコア9388

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

yoichiro_ito

2016/07/19 13:32

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

2016/07/19 13:41

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

2016/07/19 13:51

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

0

こんばんは

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

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

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

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

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

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

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

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

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

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

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

投稿2016/07/19 13:21

Mr_Roboto

総合スコア2208

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

yoichiro_ito

2016/07/19 13:37

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

0

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

投稿2016/07/19 13:06

takasima20

総合スコア7458

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

yoichiro_ito

2016/07/19 13:11

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

0

phpMyFAQ 2.9

FAQに特化したCMSです。

投稿2016/07/19 13:24

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

yoichiro_ito

2016/07/19 13:29

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

退会済みユーザー

2016/07/19 13:32 編集

要件を満たすのであれば出来合いのものを使うというのもアリですね。
退会済みユーザー

退会済みユーザー

2016/07/19 13:33

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

2016/07/19 13:39

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

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問